I'm using DebugDiag for the first time, and I'm using it on Windows 7 x64. I've created a crash rule for (x86) myprogram.exe, which is guaranteed to crash because I've coded it intentionally to crash with an "unknown exception (0xc0000417)".
I have windows "startup and recovery" configured to capture mini-dumps. It works. I've adjusted registry entries to capture custom mini-dumps. It works. Yes, I'm getting two different dump files as a consequence. It's ok by me.
But if I understand correctly, DebugDiag should simply "jump to life" when the crash rule is triggered, but instead DebugDiag does nothing when the crash happens. DebugDiag only provides analysis if I explicitly load a dmp file manually into it. What do I need to do to make the rule auto-trigger?
I assume you are using version 1.1 of DebugDiag.
I'm afraid it is not fully functional on Windows 7.
In version 1.1, the analysis-only version is installed and leak-tracking and dump generation does not work.
If you plan to generate dumps on application crash, you can use ProcDump from SysInternals with -e -ma flags.
DebugDiag 1.2 is available since july. You can download the packages from this page.
Related
There is a bug that I would like to fix that only occurs on Windows Server without a GUI running. I have set up a Windows Server 2019 machine on Google Compute Engine that reproduces the bug, and would like to debug it.
Ideally, I would like to use gdb, but seeing as the program was built with Visual Studio 2019, gdb can't read the debugging symbols.
I don't have a Windows machine, so using Visual Studio will be difficult. I could set up a VM, but if there's an in-terminal way to do this that would be preferred.
I did a pretty thorough Google search, but it didn't turn up anything. Is there really no Windows solution for debugging C++ code headlessly?
MS has 2 console debuggers called CDB and NTSD so you don't actually need Visual Studio GUI to do the debugging. In fact there are a lot of debugging environments in Windows from MS beside the usual Visual Studio. Just install them in your Windows Server and control them remotely from your terminal
You can also debug MSVC-compiled code with LLDB since the PDB format has been published long time ago and LLVM on Windows does support it. No idea about current LLDB on Linux though
And since you have the source code, sometimes the old-school printf debugger is the best way to analyze the issue
If you can get a Windows VM it'll be much better to do remote debugging. In fact almost all debuggers support that feature including GDB or LLDB, so even if you don't have the source code you can still run any Windows debugger and step through the instructions instead of high-level code lines from a remote machine
An alternative way is to take a memory dump and debug later. After getting the dump file, just drag it into your VS solution or any debugging tool like WinDbg and then select "Start Debugging". Now you can step through instructions/code lines and examine variables' values, or jump to an arbitrary function's stack frame just as if you're really running the malfunctioning app
There are many ways to dump a process' memory. You can set Windows to automatically save a dump file when your app crashes, or just capture memory snapshots manually during runtime. Comparing 2 snapshots is also useful for detecting leaked memory. For more information on how to do that read
Collecting User-Mode Dumps
Steps to Catch a Simple “Crash Dump” of a Crashing Process
There's also an easy way to take a dump of a live process using task manager (or any other similar tools)
Creating a ATL COM DLL in Vs2015 for a VB6 consumer is going badly because the "fault tolerant heap shim" is being applied to VB6, which I am running from the vs2015 debug command.
I have found many posts about disabling FTH in Windows 7, and indeed I have applied them all, including deleting the DLL in \Windows\AppPatch, as well as disabing FTH in the registry AND running the rundll script that is cited.
Still, this damn thing is making it impossible for me to debug the dll, because the FTH makes it run like a dog under VB6 in debug mode.
I even added "vb6.exe" and "full_path_to_vb6.exe" in the exclusions list in the registry -- to no avail.
I desperation, and needing to get some work done today, I have renamed vb6.exe to myvb7.exe (!) and this gets rid of the FTH alert in the VS debugger. But why can't I disable FTH for vb6.exe?
In fact, why does it even get enabled at all when a debugger is attached? It's driven me mad today.
Anyone?
There wasn't too much help forthcoming on this. For future reference, if the application (in this case VB6) is set to run in compatibility mode (either from a right click on the shortcut you use to launch it, or from a property set on the target exe itself) then nothing you do will release the shim!
Solution: don't run vb6 in compatibility mode under Windows 10!
I set Qt Creator to break when a C++ exception is thrown:
I then tested it with this code:
try {
throw std::runtime_error("error");
} catch (std::exception &e) {
qDebug("%s", e.what());
}
But it didn't break on throw std::runtime_error("error");. I'm using CDB, not GDB, because I'm using the MSVC Kit.
Edit: There is another question where CDB is working for the OP, even if slowly. So it should work in principle. My configuration is: Qt Creator 3.3.0, compiling with Qt4/MSVC 9.0 (x86), the debugger is CDB 6.2.9200.16384.
Edit 2: This is what I'm getting in the CDB log window (I made a diff between the CDB log with and without the breakpoint):
<bu100400 CxxThrowException
<!qtcreatorcdbext.breakpoints -t 1 -v
<!qtcreatorcdbext.pid -t 2
dATTEMPT SYNC
d*** Bp expression 'CxxThrowException' contains symbols not qualified with module name.
1 breakpoint(s) pending...
*** Unable to resolve unqualified symbol in Bp expression 'CxxThrowException' from module 'C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18201_none_ec80f00e8593ece5\comctl32.dll'.
Full CDB log (in case needed): http://pastebin.com/jhNRy9bE
Edit 3: #HansPassant's explained why it fails in the comments:
Keep in mind that you are using a very old version of MSVC++, big changes at VS2012. The pastebin shows it being out of sync pretty badly, never getting to the DLL that contains __CxxThrowException#8 (MSVCR90D.dll) before the exception is thrown. It is simple with the sxe debugger command, automatic break when any exception is thrown.. Maybe you shouldn't be using QT's UI at all, it looks too gimpy. – Hans Passant 10 hours ago
Just look at the trace, the debugger shows what DLLs it is searching for "CxxThrowException". It never gets to msvcr90d.dll. And the exception is thrown while it is searching for the symbol after which it all ends. Completely out of sync. – Hans Passant 56 mins ago
I'll just write up why this is going wrong, a workaround is going to be difficult to find. The debugger trace in your pastebin tells the tale.
The basic issue is that the communication between the debugger and the QT front-end is rather poor. And in your case it gets out of sync, QT doesn't wait long enough for the debugger to complete the command. QT tries to set a breakpoint on the msvcr90d.dll!__CxxThrowException#8 function, the one that raises a C++ exception in the Microsoft CRT. This function can be present in more than one executable file if the program uses multiple CRTs. A pretty common mishap, caused by building with /MT. And sometimes intentional if you use a well-isolated DLL that you interface with by using COM.
This takes a while as you might imagine, the complaint in the linked question, the debugger has to plow through the symbol information for every DLL that's loaded. It will take especially long if the PDB for the DLL needs to be downloaded from the symbol server and doesn't otherwise get cached so it is available the next time you debug. Not your issue afaict, it does setup the cache location to C:\Users\sasho\AppData\Local\Temp\symbolcache. Go have a look-see to verify that you do see PDBs for the operating system DLLs there.
This operation is tricky, the debugger doesn't give a good signal that it is done searching the DLLs. What the QT should do is verify the debugger feedback against the list of DLLs it obtained. It does not do that, it issues the g command before the debugger is done searching. Could be a timeout that is too short but it actually looks like QT doesn't count on the debugger performing this command in the background. A convenience to a human, not exactly very helpful here :)
There ought to be a way to configure CDB to not perform this search in the background. This is well-hidden, I don't see anything in the debugger.chm help file but it probably wasn't updated in a while. Google doesn't help either. I'd recommend you ask a question about it. Most significantly perhaps is that you have a rather major mismatch in version numbers. The compiler you use is 2008 vintage, the debugger is quite new, SDK 8.0 version, I can't tell what QT version you use.
So a possible workaround is to intentionally use an older version of CDB, one that's more likely to have been tested with the QT front-end version you use. Download the corresponding SDK version, version 6.0 matches the VS2008 time frame. I think the "Debugging Tools for Windows" was still a separate download back then and not yet included in the SDK. Another workaround is to stop relying on the friendly QT front-end and learn to drive CDB from the command prompt. Moderately more useful is WINDBG, uses the same debugging engine but has a GUI interface. Just moderate, it is still mostly prompt driven. You do lose several days of your life learning the commands however. Getting the debugger to break when an exception is thrown is trivial, use the sxe command.
I have a Visual Basic 6 application that I've recently changed to use a couple of C++ DLLs I've written in Visual Studio 2008. The application works fine on my PC, but when we install it on one of our test PCs it tends to crash during shutdown - we see the Win 7 message "Your application has failed" or whatever it is.
I know Win 7 stores data that can be used to analyse the crash. I've got the source code and .PDB files from the build so I should be able to use that, but I can't figure out where Win 7 stores the data from the crash. The Event Viewer shows the crash but doesn't have any data and the directory C:\Windows\Minidump doesn't exist.
Where do the crash files get put?
Microsoft has documentation here which works back to Vista Service Pack 1:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
There is a registry key with 4 sub-values that control generic crashes:
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
DumpType # 1 = mini-dump, 2 = full dump, 0 = custom dump
DumpCount # Maximum number of dump files to keep before purging
DumpFolder # Full path to folder to store dump files (no trailing slash)
DumpFlags # Usually 0, flags only used if DumpType is 0
Once these registry values are in place crash files should be immediately written no matter what happens to whatever dialog might be displayed.
Note: Registry sub-keys with executable name can be used to control crash behavior for only one specified process.
Get minidump for crash
Get WDK , Using Debugging Tools for Windows
Use Windbg to open crash dump
use command !analyze
The !analyze extension displays information about the current exception or bug check.
Read more about window debugging
Creating Dump:
You can configure windbg as defaut debugging tool by giving command "windbg -I" in run.
Also Dr. Watson tool can do this for you.
You can even use a carsh reporting mechanism and get the locally saved dump file, then debug it using Visual Studio. There are pretty much freely available resources in Visual C++, but not much in VB.
Why don't you make your program save minidump wherever you want when the crash happens? I'm not familiar with VB, but try to use SetUnhandledExceptionFilter() and MiniDumpWriteDump().
I'm trying to generate a release build for a C++ application that I've written. The application runs fine (debug & release) when you run it from within VS2008; but when you run the executable it crashes nearly every single time.
Now, is there a hack so I can run this application as a standalone application without having to run through all of the code and finding the bug that is causing it?
Thanks in advance.
In short, no.
you will have to find the bug, if it works within VS, then I'd hazard a guess that it is a timing issue, possibly you're overwriting shared thread data, this would be less likely (though still possible to see) inside VS as its being run in a debug environment which slows it down a bit.
If you want help finding your bug, then tell us more. Otherwise, build your release with debug symbols (pdbs), install DrWatson as the system debugger and run it standalone. When it crashes DrWatson will create a minidump file, load this into WinDbg (my favourite) and you'll be able to see exactly where your bug is (it'll even tell you that the dump contains an exception and show you it by default. You need to add your source code path and path to your symbols in WinDbg to get it to do this correctly).
Then you will also know how to diagnose crashes when the app is run on-site too.
Are you loading external resources? If you are check that your relative paths are correct in the C++ program.
One possibility is that your program uses uninitialized heap data. Launching a program from the debugger enables the NT debug heap, which causes the heap allocator to fill new memory blocks with a fill pattern, and also enables some heap checking. Launching the same program from outside the debugger leaves the NT debug heap disabled, but if the program was linked against the debug version of the C runtime, then the CRT debug heap will still be enabled.
A much less likely possibility is that your program requires SeDebugPrivilege to be set in its process token. The debugger enables this privilege in its process token, which has the side effect that all programs launched from the debugger inherit this privilege. If your program tries to use OpenProcess()/ReadProcessMemory()/WriteProcessMemory() and doesn't handle errors correctly, it's conceivable that it could crash.
There are a few possibilities. Besides what has already been mentioned, running an app from Visual Studio will execute in the same security context as the Visual Studio instance. So if, for instance, you are working on Vista, you might be hitting an unhandled security violation if you're trying to access protected files, or the registry.
What if you build a debug version and run it standalone? Does it crash? If so, you can usually break into the debugger from there and get a call stack to see what the malfunction is.
From the details you've given, it sounds like there may be a library issue. Are you running the program on the same computer? If not then you'll also have to deploy the appropriate libraries for your application. If you are running on the same computer but outside of the dev environment, ensure that your application can see the appropriate libraries.
Best way i have found to debug in release is to create a crash dump when an crash happens and the dump then allows me to load debug symbols on my dev computer and find out whats going on. More info here: http://www.debuginfo.com/articles/effminidumps.html
You can also go to file => open in Visual Studio and open the .exe, so you are not starting it under the debugger per se. Not sure if it will help.
http://blogs.msdn.com/saraford/archive/2008/08/21/did-you-know-you-can-debug-an-executable-that-isn-t-a-part-of-a-visual-studio-project-without-using-tools-attach-to-process-296.aspx