I have a test suite that runs a Windows executable with a variety of command line options to test that the executable works correctly. In some test cases, those arguments cause the executable to break badly and this dialog appears:
Unfortunately, this dialog remains until I manually press Abort, Retry, or Ignore. This prevents me from running these tests in an automated fashion. I have tried calling the executable through the Windows CDB Debugger with a variety of CDB options with no luck.
How can I prevent these dialogs from appearing or automatically continue on with the tests?
It is clear from the window title that you are testing the Debug build of the program. This is not a good practice, you are not testing the program the way it is going to run on your customer's machine. A Debug build is suitable for the programmer to debug their code. But it does occasionally hide a bug. Such bugs can be very hard to diagnose, you need tests to flush them out. You are not performing such a test.
Only test the Release build. Which then also automatically solves this dialog problem, the Release version of the CRT doesn't display it.
Btw: test failed.
As documented in the Microsoft C Runtime Library manual page on abort(), this message box is expected when you link to the debug version of the Microsoft CRT. You can link to the release CRT to avoid the message, but instead Windows will trap the crash (as abort() is considered to be a program crash by the CRT) and you would see a Windows Error Reporting message instead.
The manual page also says that you can disable the message box in code using the Microsoft-extension _set_abort_behavior() function. If you go that route, you might want to have some way to control whether the message is enabled, using command-line switches or something similar.
Related
I ran into the following issue using Pascal/FPC/Lazarus, but I think it is universal to all Windows .exe files, regardless of the IDE/compiler they are created with:
I created a Windows GUI application and wanted to display some debugging infos in a simple text console. Usually in a Pascal console application Write and WriteLn are used to write to a console/StdOut, but without additional measures in the project configuration this crashes because in a GUI exe (at least if created with Lazarus) a console window does not exist, I get a "file not open" exception.
There are multiple ways in Lazarus (centered around controlling the -WG switch during the build process) to get a console attached "write /writeln" can write text to, this is not the question. My question is, whether support for a console device (StdIn, StdOut, StdErr) is a Windows feature, which is part of the Windows Runtime, probably controlled by some metadata embedded in the exe, which in turn is controlled by this -WG switch, or whether it is a feature of a runtime environment added by a specific development environment, in this case by the Lazarus IDE or a runtime coming with the underlying FPC compiler.
Thnx!
Yes, consoles are generally not used for Windows GUI apps, though you can afaik instantiate some with allocconsole manually. Very early versions of Lazarus did this.
As David says, in general on Windows Outputdebugstring() is used or a logging library.
Technical details: afaik all windows processes (so also console) must actively activate the console, a task typically done by the runtime. The -WG switch suppresses this by setting a special IsConsole boolean variable to false.
The console io initialization is in rtl/win/syswin.inc procedure SysInitStdIO around line 515.
In there you can see that if not IsConsole a dummy file description is made (assignerror), and errors are redirected to message boxes(and might pass by GUI users unnoticed).
I'm writing some software that involves Qt, GStreamer, and RTI Connext DDS. On Windows the code hangs at a certain point under certain circumstances.
Just before this happens, the message "Buffer creation failed" is printed on the console. However, this message does not occur in my code, so I assume it is generated by a dependency.
I've attached the Visual Studio debugger to the process, but because DDS is a proprietary library that was compiled in release mode, I have to compile all my code in in release mode, so it appears there is very little information you have access to. I tried to set a breakpoint on printf and puts, but this never triggers.
On Linux I'd poke around with gdb, strace, strings, and what not to try and locate the source of the message, but on Windows I have really no idea how to do these things.
I have an old VB6 app that uses a lot of 3rd party components, not just visual but also for audio processing, tcp/udp, VoIP, etc...
When I run the app as an EXE (e.g. not in the VB6 IDE), it will crash sometimes with a GPF. It happens after the program has been running for several days and occurs when there is no one around.
Unfortunately the user has clipped the screenshot, but it typically doesn't have any useful information anyway. The description of the crash reported that the crash occurred in ntdll.dll.
My questions:
What tools do I need in order to debug this?
How do I actually get started?
I have the PDB files from the compilation in VB6. The app is compiled to Optimize for Fast Code. What can I do with them in this situation?
I would use ntsd or windbg (link), and run the app under either of the user mode debuggers (if you're not familiar, they have the same commands - ntsd is a console debugger, while windbg is a GUI debugger). Both have a lot of command line options, but ntsd appname.exe will be enough to get started. Use the .sympath command to point the debugger toward the symbol, and you should be on your way. When the crash occurs, you can examine variables and stack in order to figure out what may be missing.
BTW - the error above is an invalid handle error, so the program probably passed a stale or NULL handle to a windows function. The debugger will tell you more.
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.