I have configured my windows 7 to create mini dump files on crashes but when my application crashed, no dump file was created. The search for answer left me rather confused as to when are dump files created, when windows crashes or my application crashes?
In my case, I am looking for dump file when my application crashes. I receive a typical crash dialog that states:
TheApp Application has stopped working
Windows can check online for a solution to the problem
-> Check online for a solution and close the program
-> Close the program
-> Debug the program
So can I generate dump file for my application when it crashes? I can't produce this bug on development machine so I want to walk back from dump file. Is there any other option to trace the source of bug (to source code)?
First of all, there are different places to configure a "create a minidump on crash" setting, which are totally different.
You can configure Windows to create a kernel dump file when Windows crashes, i.e. when a Bluescreen of death (BSOD) occurs. This is done in the following screen on Windows 7:
You can configure Windows to create a user mode dump file when an application crashes, i.e. instead of the "Windows Error Reporting" dialog which would normally appear. To do so, and you know that in advance, then configure a Registry key called LocalDumps (MSDN). By default, dumps will be created below %LOCALAPPDATA%\CrashDumps and they will have the naming scheme app.exe.<PID>.dmp.
For the sake of completeness, there might be other triggers. The only sure way to tell is: when the method MiniDumpWriteDump (MSDN) is called.
I'm quite sure that you want option 2 of the above. If you have trouble with it, see whether all the conditions for LocalDump are fulfilled.
The answer given by #antlersoft does not work, for the reasons I have posted in my blog: at the time the dialog is shown, Windows has triggered a breakpoint to stop the application and it has injected a callstack of Windows Error Reporting. All in all, not a good starting point for debugging.
What would work is:
attach a debugger of your choice
press "Go" in the debugger
press the "Debug" button of the WER dialog
confirm the warning about the debugger which is already attached
click "No" when asked to start debugging using the selected debugger
Using Task Manager to create a crash dump is not recommended, since it will not consider the bitness of the application, which may cause trouble later. See ways to create good and useful crash dumps.
Minidump is created when Windows crashes. It's not intended to application crash.
If you want to debug crashes of your application, you may attach it to a debugger after it is started. Clicking on the "Debug" button when application crashes do the same. You can use the debugger of MS Visual Studio to do that, for example.
See this page for help on attaching a process to MS Visual Studio debugger:
https://msdn.microsoft.com/en-us/library/3s68z0b3.aspx
EDIT: following text removed, as this may not work as expected (comment from Thomas)
You can also create a dump file from task manager, however you will still need a debugger to analyze it and, actually I am not sure you will be able to get the dump file at the point application crashes. The best way, if you can, is to debug the process on the target machine by attaching it to debugger either after it is started or when crash occurs.
When you get the crash dialog, go to Task Manager, find the process, right click on the process, and select "Create dump file". The dump file is created in the AppData/Local/Temp folder for the user; it will be named %AppData%\Local\Temp\.DMP; if you create multiple it will be -1.DMP, etc. You can move the dump file to your development machine and open it within Visual Studio. Visual Studio will then act as if you had hit "Break all" at the point of the crash while running the process in the debugger.
Related
I have a program that I have written that crashes and I'm in the process of debugging it.
However, the issue is that when I attempt to create a new build, very frequently (but not always!) I get the message:
Cannot open file 'TheExecutable.exe'
I am then unable to delete, rename, move, or in any way modify the executable until the system is rebooted. Attempting to do so in Windows explorer gives
The action can't be completed because the file is open in TheExecutable.exe Close the file and try again.
This behavior isn't unique to the particular crash I'm dealing with right now, nor the particular program. Development is becoming a headache as every attempt to debug will now take several minutes to reboot and bring all my tooling back up.
What, if anything, can I do to prevent Windows from "locking" the executable in such a fashion?
No running process for that executable is visible in Task Manager
Full details of build system:
Windows 10
Intel Compiler, 19.1.0.166 Build 20191121
nmake
C++14
Your process is not being terminated all the way. Since it is not list in the task manager, you can use PSKILL to end it manually.
Open power shell or the console in administrator mode and run
pskill name_of_executable
and it should terminate it so you can re-run it.
I cannot get dump files created with Task Manager (32 or 64 bit) or Process Explorer to give useful results in WinDBG or Visual Studio 2015, whereas the dump written directly from VS works brilliantly in both. I need Task Manager dumps to work so that I can analyse dump files sent by my end users.
I have reduced the problem to the simplest possible Win32 application, created in VS 2015 C++, with a deliberate NULL pointer write to cause an exception. If I run the program in VS and use Save Dump As when the exception occurs, then the dump file can be used in VS and WinDBG to see the code causing the problem. This is as expected.
However, if I run the application outside of VS, then Windows shows the usual dialog:
“Win32Project.exe has stopped working … Debug / Close Program”.
Whilst this dialog is still active I go to Task Manager 32bit and select Create Dump file. But loading this dump file into VS or WinDBG gives no useful information. In particular VS shows Exception Code as “not found”. Clicking on “Debug with Native only” causes “The application is in break mode to be shown”. See below…
I am running a new Win 10 64bit PC. DMP, PDB and EXE files are in the same directory, and I have tried endlessly with symbol directories
Visual Studio 2015 output after loading .DMP file:
Dump Summary
------------
Dump File: Win32Project1 (4).DMP : C:\Users\Rob\AppData\Local\Temp\Win32Project1 (4).DMP
Last Write Time: 24/08/2017 16:38:27
Process Name: Win32Project1.exe : C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe
Process Architecture: x86
Exception Code: not found
Exception Information:
Heap Information: Present
System Information
------------------
OS Version: 10.0.15063
CLR Version(s):
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Win32Project1.exe C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe 0.0.0.0
ntdll.dll C:\Windows\System32\ntdll.dll 10.0.15063.447
kernel32.dll C:\Windows\System32\kernel32.dll 10.0.15063.296
...
Why does that happen what you see?
It works in Visual Studio because the debugger is already attached. The debugger is informed about the exception before the process terminates. The debugger will halt the process before the Windows Error Reporting Dialog occurs and create a crash dump when the original exception is still active.
To learn more about the process on how exceptions are passed from the program to the debugger (first chance), back to the program (catch block), to the debugger again (second chance) and finally to the OS, google for the term "exception dispatching".
It does not work with Task Manager, because exception dispatching is already in its last state, which is "get handled by the OS". This makes Windows halt the program by making use of a breakpoint. It then shows that dialog. When you create a crash dump now, it's too late and it's very hard to get useful information from that crash dump.
What options do you have?
a) Windows Error Reporting
The mechanism that applies here is called Windows Error Reporting. If you had an account at Microsoft, your customer could simply click the "submit" button. You would then get some information from Microsoft. The way you ask the question makes me assume that you don't have such an account.
Then, use a feature called LocalDumps (MSDN). It's a Registry key to configure Windows to save a crash dump on disk. Make sure you understand what you need from such a dump in order to configure it correctly. In doubt, have a look at How do I take a good crash dump for .NET and use the same settings (full memory user mode mini dump). It will be good for C++ as well.
It might even be possible to activate this Registry key while the dialog is shown but I have not confirmed this any more since 2014 and I can't recommend it.
Check if your settings work by using your null pointer dereference sample application. To do so, rename your executable to the same name as your actual program.
b) Attaching a debugger
Attach a debugger to the process, then let the application continue. Press "Debug" on the dialog and confirm the message that says "a debugger is already attached". The second chance exception is thrown again, the debugger will get it and you can take a crash dump.
If you need screenshots, see my article about it
Note that in approach b) you can make many mistake which will lead to improper results. The safe way is to activate LocalDumps as described in a)
I recommend giving ProcDump from Windows Sysinternals a shot. You can set it to capture a dump of your app when it crashes, or set it as the Just-in-Time debugger and have it write a dump for any app crash.
See the documentation and examples in the above website for more detail.
I have a strange problem using Visual Studio 2010.
I'm running a DLL, which is loaded from IIS in the process w3p.exe from Microsoft. When I start the remote debugger on another machine and attach my local machin there, everything is fine and I can debug.
The problem is when I run it locally. I know that the DLL is loaded (because of logfiles) and I can attach the debugger to the process. But when I try to Break all I get an error saying
Unable to break execution. This process is not currently executing the type of code you selected to debug.
The project settings are definitely pointing to the project that just compiled the running DLL, so I don't really understand this error message.
Also when I set breakpoints nothing happens. The debugger is attached though, because when I stop IIS then I get an error message telling me that the debugger needs to be stopped first.
I'm using an intentional application error fopen(NULL, NULL) which will allow me to attach a debugger in the debug build. But this is rather annyoing, because I have to clear the call stack manually before I can actually start debugging. Using __debugbreak() doesn't help, so I have to use this clumsy workaround.
So can anybody tell me why this works remotely, but not locally?
So I finally found a solution to my problem.
When opening the attach dialog there is an option Attach to: Managed... with a Select button beside it. By default this was set to Managed (v4.0). Now I added Native code and this solved my problem. I can attach now locally as well.
I sure don't understand why this works on a remote machine, because the code is exactly the same though, so there shouldn't be such a difference.
I left a program running last night, it worked fine for about 5 hours and then one of its built-in self-diagnostic tests detected a problem and brought up a dialog box telling me the issue. The program was built with debug information (/Zi). Is it possible to somehow get the debugger started so I can examine the value of some variables within the program? Or is it too late?
You can attach the debugger to the running process:
Debug > Attach to Process...
Just open up the program's solution first.
Assuming you've still got the error dialog on the screen you can break into the program and work back up the call stack examining variables etc.
For the future crashes ... if you have windbg or Visual Studio Professional, you can debug crash dumps, even when program isn't running. It is quite useful sometimes. See "MiniDumpWriteDump" on MSDN for more info.
Other than that it is "Attach to process".
Professional edition of Visual Studio have Just-in-Time debugger, that will kick in as soon as anything crashes, even if MSVC wasn't running. It will also locate source code (if debug info and source code are available) and open/create solution for you.
There is an option in the Debug menu to attach the debugger to a running process, IIRC.
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().