I am having serious trouble getting the JIT debugger event trigger when using the Stop statement on my scripts.
Me an 2 other coworkers have been doing research on the issue and none of us can figure out what is the problem. We have uninstalled and reinstalled Microsoft script editor, and we have updated the registry values, we have added ourselves to the debugger users group. We have admin rights etc.
Not using this debugger is not an option, is a project requirement but we cant get it to work on 2 of our machines. However, the team leads machine does work. but we have 2 machines that the debug event does not trigger. When comparing settings everything seems to be in order.
We have followed the instructions on MSDN and various other found around the web.
Is MDM.exe running in Task Manager? (it's a service, Machine Debug Manager).
cscript //x nameofscript.vbs work?
stumbled on this post one year after... hope in the meantime you found a solution.
I have too the problem when I need to JIT-Debug my VBS Scripts; I 've realized that the debugger won't fire up upon Stop statement but only in case an Exception is thrown; After you are in debug mode, then, Stop statements should work again, but you need to generate an exception in order to invoke the debugger.
When I need to break a VBScript, I usually put a call to a non-existing function in order to intentionally cause an ecxeption: this will trigger the debugger and I'm able to work with it.
Sample code:
(do something)
DEBUG_INVOKE ' Function DEBUG_INVOKE does not exist => Exception.
' you can actually type whatever you want, eg. 'stp', 'stopp', 'xxx', etc.
' provided, of course, it's NOT the name of a Sub or Function present in
' your script.
(do other stuff)
After you enter debug mode, then, you may not be able to move from break position: it depends on the debugger: I know, i.e. that MS Script Debugger and Visual Studio 2015 Community Ed. do like this, while MS Script Editor and Visual Studio 2010 Professional allow you to move the pointer and do step-by-step debugging. Still investigating on this!
HTH,
Max - Italy
Related
I'm running in to an issue where my solution freezes when debugging. If I place a breakpoint at the beginning of the solution, it wont freeze and will allow me to either continue or step through just fine. With this solution however, I need it to start from a specific point in the code. When I try to start it from that specific point, it'll freeze, and the output and locals box will have a popup in each saying "Busy..". It did not have this issue a few days ago, but just started yesterday.
It only occurs to this specific solution (I can debug other solutions just fine). Using C#/.NET mostly.
Remedies I've tried: Clean/Rebuild, repair on installer, uninstall just app, uninstall app and associated files, running Release, code cleanup, upgrading/downgrading vos, placing breakpoint at beginning then jumping to next breakpoint at specified point, removing antivirus software temporarily
Running latest version of Visual Studios 19 Community at the moment.
I didn't find the solution necessarily, but deemed it to be an issue with the "Locals" box that displays all your local variables and values. If I close out of this, I can continue with debugging. From further research, it seems that tool has been known to be pretty buggy.
I've been fighting this little problem for a while now, so I'm really hoping I can get some help. I've been looking for a solution to this, and I found this SO question: Debugging doesn't start.
My issue is somewhat similar to the issue discussed here, except that my issue is a two-parter.
Part 1: Similar to the issue discussed on the other question. (Debug Window Doesn't show up)
When I attempt to launch my Windows 32 console application project (The simple kind that opens in the windows CLI). The CLI (or CMD) window doesn't open, and windows idles giving me a spinning cursor wheel. Visual Studio IDE (I'm using VS 2013 Community) becomes unresponsive and I cannot access any menus, or use any hotkey to "Stop Debugging". One difference from the provided SO question though, is that when I try to launch "MyProject.exe" from my project's "Debug" folder I get the same result as attempting to debug in the IDE.
Part 2: Unkillable Process
When I try to close my debug application in the windows task manager, it is not listed as an ongoing process. However, whenever I try to manipulate, delete, or otherwise modify my Project.exe application (in my Project's "Debug" folder), windows informs me that the application is in use. Confused by this, I downloaded two applications. The first was Process explorer, which showed me that I did in fact have 2 instances of "MyProject.exe" running. The second was Process Hacker, which also showed me 2 instances of "MyProject.exe". However, neither of these programs were able to terminate either of the "MyProject.exe" processes.
I am capable of terminating the processes for visual studio and restarting the IDE, however, because the "MyProject.exe" processes are still running. Building always fails with the error
"Error 1 error LNK1168: cannot open C:\Users\Brandon\Desktop\MyProject\Debug\MyProject.exe for writing"
Whenever I restart my computer, the lock files (as expected) are removed, and the "MyProject.exe" processes disappear. I can restart VS and everything works, but if I try to Debug (pressing "Start Debugging" or F5) the same issue occurs.
A process of my program is started ("MyProject.exe"), but the CLI window where my program's text should appear doesn't show up. Visual studio locks up, and "MyProject.exe" persists until the next restart because "MyProcess.exe" cannot be terminated.
My solution configuration is set to "Debug", Solution Platforms = Win32.
I have tried creating a new blank console project in VS 2013 and I get the same result: code builds fine, but I have the same debugging issue. I get an identical result with a quickly assembled "Hello World" project.
Sorry for being a noob, but honestly. I really don't know what's going on, so any help is greatly appreciated.
(Note: Running Windows 10 with VS2013)
EDIT (UPDATE):
So, I'm having the same problem with several programs in Windows 10 (most notably Allegorithmic's Substance Painter). So it looks like this may actually be an OS problem. Several of my programs whenever I try to launch them do the same thing...the program acts like it's going to launch, but then no usable window appears. Looking at my processes I can see that the process has been started, but it is once again unkillable. For reference, I am using Windows 10 Version 1511 (OS Build 10586.17).
I believe your problem might be Avast, if you are running it. I had exactly the same issues until I uninstalled it. Had upgraded to Win10 and VS2013 just froze, same as you described.
Cheers.
I have a Windows Service and I would like to see what it's doing when it starts up. Normally to accomplish something like that, I'd hard-code a Thread.Sleep for like 10 seconds to give me enough time to attach the debugger. This is effective, but annoying, as I need to re-compile once to put the pause in and again when I (hopefully remember to) take the pause out. I know I could alternatively hard-code a break command in, but that also requires me to re-compile my solution.
I know I can also separate my service's logic into a separate project that can be run in Visual Studio, which I can use most of the time, but sometimes I want to see exactly what my service is doing when it's running as a service.
Is there a way that I can get my debugger attached to my service so that I can see the things it's doing on startup, without hard-coding and re-compiling anything?
There is a registry key which gives you a chance to attach a debugger to the process as soon as it is created.
Save the following snippet as a *.reg file and import to your registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\services.exe]
"Debugger"="c:\\Program Files\\Debugging Tool For Windows\\windbg.exe"
remember to change 'services.exe' to the actual services executable file name.
You can also use the gflag tool to facilitate the work. For detailed information please check KB 824344: How to debug Windows services
Take a look at Attach to a process on the Tools menu in Visual Studio. You can put a break point in your code and then start the process and debug the service. You may have to put a thread.sleep() to give you enough time to react.
You have to start the service than attach to the process in Visual Studio. The thread.sleep() will give you the time to perform the attaching without blowing by your start up code.
Here is Microsoft's advice on how to accomplish this: http://msdn.microsoft.com/en-us/library/7a50syb3%28VS.80%29.aspx
I have a VB app that I need to monitor while it is running. I added some variables to the Watch window, but while the app is running the watch window is greyed out. The only way that I have found to see the variable values is to use Debug -> Break All, but this stops the program.
I have used other IDEs and they allow active variables to be monitored. Is this possible in VS?
Sorry if this is a noob question.
UPDATE: To be clear, my app is communicating with a piece of lab equipment and and as data is sent or received or errors are detected counters are incremented. I would like to watch these counters but I don't want to build a screen to do this since they are for debugging. I just assumed that this is basic functionality in any IDE
SHOCKED: It seems that Visual Studio does not offer this (what I would consider) basic functionality. For those that seem to think that this is not possible with an interpreted language, consider this thought experiment. If you pressed Break All quickly followed by a Continue then you would refresh the watch window - correct? Why then can't Visual Studio do this as a single Refresh Watch command or better yet allow this function to automatically run at a period specified by the user. No debug writes, no log files, no stopping your program mid-stream and creating timeouts. I am just shocked that you cannot do this. Its a little like not having breakpoints.
Which IDE or development environment shows - in real time - the values of variables in the Watch window, without having to hit any breakpoints, while the application is running?
Visual Studio doesn't provide this. In order to get updated values in the Watch window, or edit items there, the app needs to be at a breakpoint or debugging.
After you've done "break" to give control of the program to the debugger, then you can "step" through the code using function keys like F10 and F11. During each 'step', the program evaluates one or more statements; after each step it stops (until the next step), and while (only while) it's stopped you can 'watch' its current state.
There are other ways too to break into the debugger (to use the Watch window while the program is stopped): other ways like to set 'breakpoints', and use the 'run to cursor' feature.
Of course, but stopping a program that is actively receiving or sending data to a some other process, driver, etc, stops this communication and causes timeouts and other problems.
That's true. To watch values change in real-time, I use a log file:
Add statements to my code, such that when I change the value of a variable I emit a new line to a log file (showing the changed value)
Run the program
Watch new lines being appended to the log file using a utility like tail -f.
I've never see a debugger with the functionality you mention. The closest thing to the functionality you mentioned (and which isn't exactly the functionality you mentioned) is How to: Set a Data Breakpoint (Native Only).
What you're attempting to do is not possible in Visual Studio. All of the variable inspection windows (watch, locals, autos, etc ...) rely on the debugee process being in a break state in order to function.
This is true of essentially any debugger I've worked with in the past. At least those which use a compiled language.
I'm curious as to what IDE's you're referring to? Did they deal with interpreted languages?
Make sure you are in "Debug" build and Microsoft Debugger is running as a service and not blocked/disabled.
This should help you: How to trace and debug in Visual C++ .NET and in Visual C++ 2005
my 88 year old memory remembers an old version of visual studio allowing a watch window to function while debugging.
OK, just me.
We are using VS 2008 Team System with the automated test suite, and upon running tests the test host "randomly" locks up. I actually have to kill the VSTestHost process and re-run the tests to get something to happen, otherwise all tests sit in a "pending" state.
Has anyone experience similar behavior and know of a fix? We have 3 developers here experiencing the same behavior.
This may be related to an obscure bug that causes unit tests to hang unless the computer name is UPPERCASE. Crazy, I know - but I had this problem and the fix worked for me.
Bug report on MS Connect
Workaround on MS Connect
TFS Blog Article about this issue
HowTo edit the registry to change your computer name
The easiest approach is to tweak the registry. You need to edit two keys:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ActiveComputerName
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\ComputerName\ComputerName
Change value ComputerName to be upper case in both keys, and restart. Tests then magically work.
When you say lock up, do you mean VS is actually hung, or do the tests not run?
The easiest way to track down what is going on would be to look at a dump of the hung process. If you are on Vista, just right-click on the process and choose to create a memory dump. If you are on Windows XP, and don't have the Debugging Tools for Windows installed, you can get a memory dump using ntsd.exe. You'll need the process ID, which you can get from Task Manager by adding the PID column to the Processes tab display.
Once you have that, run the following commands:
ntsd -p <PID>
.dump C:\mydump.dmp
You can then either inspect that dump using WinDBG and SOS or if you can post the dump somewhere I'd be happy to take a look at it.
In any case, you'll want to likely take two dumps about a minute apart. That way if you do things like !runaway you can see which threads are working which will help you track down why it is hanging.
One other question - are you on VS2008 SP1?
I would try running the tests from the command line using MSTest.exe. This might help isolate the problem to Visual Studio, and at least give you some method of running the tests successfully.