-
<p>These are different things. You can be an user that belongs to Administrators group, and you can still be running below the "administrator" level. If you have access to a Windows machine, right click on any program on your desktop and chose "run as administrator". This does not change your user at all (you can see there is no logon involved). This extra level is made so that an user, even belonging to Administrators group, can be restricted in some actions that can change system configuration. </p>
<p>Some programs avoid running as administrator because that level allows to access resources that are forbidden to normal programs and can be used to reverse engineer a program. Thats why i asked on my post about the possibility for this behavior to be intentional by Tektronix.  In case you wonder why i want to run my program as administrator it is because some performance analysis tools need this level to work.</p>
<p>The NI stuff is possibly having some influence. I will try to clean it.</p>
-
When I say 'administrator' account I mean i raise the current user to run as administrator. I am not changing the user, so the profile is the same.<br>
I do not have other Visa sessions running. I can repeat the test under the same user, not raised to Administrator, and it works as expected. <br>
<br>
It is weird i did not detect this problem before, because I use my user raised to Administrator all the time. It might be related to some update somewhere... Also, in the past I used a NI Visa library. Dont know if it can be related to the problem. I can see parts of NI software still installed. 
-
<p>I am trying to connect to a MDO3054 scope. However, the problem happens before I can access the scope. I mean, the scope can be OFF and the problem still happens.</p>
<p>When the call fails I am just opening a VISA session, At this moment I do not know how many instruments are connected.</p>
-
<p>Thanks for your feedback, but I have updated to 4.2 and the behavior is exactly the same. </p>
-
<p>Tektronix Visa 4.1.1.22</p>
-
<br>
I have found that function viOpenDefaultRM fails when the calling thread is running as Administrator.<br>
The call to the function never returns. <br>
It works fine when the thread runs under a normal user account.<br>
Is this intentional  ? <br>
(I am compiling the program with VS2017)<br>
<br>
 
-
FYI, the problem is solved by entering again the options key. 
-
Sure, I know the video is not suitable for digital, but the problem occurs just  because I set the trigger mode *before* I change the input channel. This should not happen. In my case the source does not change by itself when I rotate the wheel, it stays at D0. It is interesting that you see your input source changing automatically.<br>
I can reproduce the problem systematically, it always hangs. <br>
<br>
It is interesting that this is fixed on MDO3104. It might seem something related to firmware, but apparently it is not.<br>
Thanks for your comments.<br>
 
-
<p>Working with a MDO3054, I have the trigger mode set to 'Edge'.<br> At this moment I have D0 as trigger. Then I decide to change it to &quot;Video&quot; on channel 1. While still having D0 as trigger input, I press trigger Menu and Type button.<br> I rotate the 'a' control knob until it reaches 'Timeout' option (although i wanted to go further to Video). I cannot go down beyond 'Timeut'; it hangs there! The scope does not respond to any action beyond this point.<br> No way to recover other than restarting the scope.&#160; if I change input channel to CH1(or any other non digital) before selecting the Trigger mode, the problem does not occur. <br> Firmware version: 1.30 (it happened also with firmware 1.26)<br> <br> Is this a known 'feature'? :-(<br> <br> <br> <br> <br> <br> <br> &#160;</p>