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.
Related
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
With visual studio you can attach to a running process, hit 'pause' (or called break), and even without symbol files or source, you've paused the process and can see a disassembled view.
I would like to achieve this but at the very start of the process. Attaching and pausing as quickly as possible is not the solution I'm looking for :)
For example, if the application was a console based c++ app, gdb can set a break point on main() [or any named function it can find for that matter]. Can something similar be done with visual studio?
But this question is for the more general case - I'd like to be able to start a process and have it pause immediately upon entry (immediately after the kernel launches the process).
http://blogs.msdn.com/b/greggm/archive/2008/09/12/attaching-a-debugger-at-startup.aspx
There are some level of support. But if I were you, I would use WinDbg directly.
I tried using the debugger in Visual C++ 2010 Express on a few files to familiarize myself with the with breakpoints, step into, and etc. but many times if I use one of the step commands (at least step into) it will open another file like "ios" or "ostream" and do the command there instead of the actual program I'm working on. It seems to always happen after the last statement in my program and once it does it won't let me use the step commands on my own program anymore until I restart debugging. It's really annoying and sometimes it won't even let me use step into, over, or out even once. It will just open "ostream" or something and use it there.
Does anyone have a solution to this?
You're stepping into the CRT (C++ Runtime). Hit Shift+F11 and you'll step out. You can avoid stepping into the runtime by right-clicking the line, and using the "Step into specific" option to step directly into your code
I'm running a test script from batch file.
Because it is test, the programs are expected to fail once in a while. It is file as long as error code is returned so I can continue and mark specific test as failed.
However there is very annoying behavior of executable files under Microsoft Windows - if something fails it pop-ups window like:
This application has failed to start because foo.dll was not found, Re-installing the application may fix the problem
<OK>
Or even better:
The instruction at "..." referenced to memory at "..." ..
Click on OK to terminate the program
Click on CANCEL to debug the program
The result is known - the script execution blocks till somebody presses "Ok" button. And when we talk about automatic scripts that may run automatically at night in some headless virtual machine, it may be very problematic.
Is there a simple way to prevent such behavior and just make an application to exit with failure code - without changing the code of the program itself?
Is this possible at all?
The answer is following: You need to disable WER.
Simplest description for this I found at http://www.noktec.be/archives/259
Simply (ON XP): Right Click on My Computer > Advanced > Error Reporting > Disable
Voila - programs crash silently!
This does not solves problem when DLL is missing, but this is much rare case and this is good enough for me.
You can suppress AV's and such from showing a dialog box by running your application, or the script (the script engine, like cscript.exe), under a debugger.
Use Gflags.exe, or modify the registry directly, and set Image File Execution Options for the image in question. See this article for details on how to use the appropriate registry keys. You can set it up using a debugger commandline like "C:\Debuggers\ntsd.exe -g -G -c'command'", where you can pass commands to ignore certain types of exceptions in the -c"commmand" argument. This will effectively give you a tool to suppress interactive dialogs as a result of exceptions like AV, and will let the process continue (presumably to immediate end after the exception has occured).
This article explains the commands you can use to control exceptions and events from withing the debugger.
The -g and -G flags make sure that the process won't break into the debugger automatically during process start and end respectively. You'll have to play with the various exception suppression options to make sure that you 'eat' all possible first and second chance exceptiosn that might cause the process to break into the debugger.
Also, if you can tolerate a process being broken into the debugger (as against being stuck showing a dialog box), perhaps that would be a better option overall. You can evaluate each debug break in batch mode at a later time and decide which bugs you care to fix.
It is possible. We used to use IBM's Rational Robot product which could monitor the screen for specific items and, if found, send keystrokes to windows and other sorts of things.
We actually used it for fully automated unit and system testing, much like you're trying to do.
Now I thought that Robot has been through quite a few name changes so it may be hard to find but there it is, right on IBM's web page and with a free downloadable trial for you. It's not cheap, clocking in at a smidgeon under USD5,000 but it was worth it for us.
There's also TestComplete where you could get a licence for just unedr USD1,000 - it touts "Black-box testing - Functional testing of any Windows application" as one of its features and also has a downloadable demo to see if it's suitable before purchase.
However, you may be able to find another product to do the same sort of thing.
I initially thought of Expect but the ActiveState one seems to concentrate on console applications which leads me to believe it may not do graphics well.
The only other option I can suggest is to write your own program in VBScript. I've done this before to automate the starting of many processes (log on to work VPN, start mail, log in and so on) so I could be fully set up with one mouseclick instead of having to start everything manually.
You can use AppActivate to bring a window to the foreground and SendKeys to send arbitrary keypresses to it after that. It's possible you may be able to cobble together something from that if you want a cheaper solution.
What is the difference between Start Debugging (F5) and Start without Debugging (CTRL-F5) when the code is compiled in Release mode?
I am seeing that CTRL-F5 is 10x faster than F5 for some C++ code. If I am not wrong, the debugger is attached to the executing process for F5 and it is not for CTRL-F5. Since this is Release mode, the compiled code does not have any debugging information. So, if I do not have any breakpoints, the execution times should be the same across the two, isn't it?!
(Assume that the Release and Debug modes are the typical configurations you get when you create a new Visual C++ project.)
The problem is that Windows drops in a special Debug Heap, if it detects that your program is running under a Debugger. This appears to happen at the OS level, and is independent of any Debug/Release mode settings for your compilation.
You can work around this 'feature' by setting an environment variable: _NO_DEBUG_HEAP=1
This same issue has been driving me nuts for a while; today I found the following, from whence this post is derived:
http://blogs.msdn.com/b/larryosterman/archive/2008/09/03/anatomy-of-a-heisenbug.aspx
"Start without debugging" just tells Windows to launch the app as it would normally run.
"Start with debugging" starts the VS debugger and has it run the app within the debugger.
This really doesn't have much to do with the debug/release build settings.
When you build the default 'debug' configuration of your app, you'll have the following main differences to the release build:
The emitted code won't be optimised, so is easier to debug because it more closely matches your source
The compiler & linker will output a .PDB file containing lots of extra information to help a debugger - the presence or absence of this information makes no difference to the performance of the code, just the ease of debugging.
Conditional macros like ASSERT and VERIFY will be no-ops in a release build but active in a debug build.
Each one of these items is independent and optional! You can turn any or all of them on or off and still run the code under the debugger, you just won't find life so easy.
When you run 'with debugging' things perform differently for several reasons:
The VS debugger is very inefficient at starting, partly because everything in VS is slow - on versions prior to VS2010 every pixel of the screen will be repainted about 30 times as the IDE staggers into debug mode with much flashing and flickering.
Depending on how things are configured, the debugger might spend a lot of time at startup trying to load symbols (i.e. PDB files) for lots and lots of OS components which are part of your process - it might try fetching these files over the web, which can take an age in some circumstances.
A number of activities your application normally does (loading DLLs, starting threads, handling exceptions) all cause the debugger to be alerted. This has the effect both of slowing them down and of making them tend to run sequentially.
IsDebuggerPresent() and OutputDebugString() behave differently depending on whether a debugger is attached.
IsDebuggerPresent() simply returns another value, so your program can react to this value and behave differently on purpose. OutputDebugString() returns much faster when there's no debugger attached, so if it's called lots of times you'll see that the program runs much faster without the debugger.
When running 'with debugging' the debug heap is used, even for release mode. This causes severe slowdowns in code using a lot of malloc/free or new/delete, which can happen in C++ code without you noticing it because libraries/classes tend to hide this memory management stuff from you.