Bugchecking a Computer on A Usermode Application Crash
Hello my name is Gurpreet Singh Jutla and I would like to share information on how we can bugcheck a box on any usermode application crash. Set the application as a critical process when the application crash is reproducible. We may sometimes need a complete memory dump to investigate the information from kernel mode on a usermode application crash or closure.
We will use the operating system’s ability to mark a process as critical and cause the system to bugcheck when the critical process closes unexpectedly. This will generate either a CRITICAL_PROCESS_DIED or a CRITICAL_OBJECT_TERMINATION bugcheck.
For this demonstration I will use the following code sample which waits for the user input and then causes an Access Violation. You can use the following steps to collect a complete memory dump for any application crash that launches fine but crashes under known repro conditions.
_getch(); //Wait for a key press
*(char*)0xdeaddead ='B'; //Causes the Access Violation
Please follow the steps below
Set the system for a complete memory dump by opening the “Advanced System settings” under System properties in control panel and then setting the value of “Write debugging information” under “Startup and recovery” options on the advanced tab.
Also enable the debug mode by running the following command from a command prompt
bcdedit -debug on
To enable the “Complete memory dump” and debug mode you need to restart the box to ensure the changes are implemented.
Run the application you want to setup as critical process but do not run the repro steps. I have compiled my test application as test.exe
Download and install the Debugging Tools for Windows, part of SDK which you can download from https://msdn.microsoft.com/en-us/windows/desktop/bg162891.aspx. Note, when the installer launches you can uncheck every feature except Debugging Tools for Windows.
We need to setup the debugger to use the public symbols. Create a folder c:\symbols. Run Windbg with admin privileges, choose “File” menu and then “Symbol file path”. Type SRV*c:\symbols*https://msdl.microsoft.com/download/symbols
For more details check https://support.microsoft.com/kb/311503/en-us
Assuming you have the debugger installed and setup with the public symbols, launch the debugger with admin privileges.
From the file menu select kernel debug and then choose the “Local” tab and hit Ok button. This will connect the windbg to the local kernel. You should see an “lkd>” prompt.
Run the following command to get the process information in windbg. The below example uses both x64 and x86 architectures
0: kd> !process 0 0 test.exe
SessionId: 0 Cid: 036c Peb: 7fffffda000 ParentCid: 02e4
DirBase: 1085d76000 ObjectTable: fffff8a0042d7970 HandleCount: 11.
0: kd> !process 0 0 test.exe
PROCESS 89038a08 SessionId: 0 Cid: 10f0 Peb: 7ffde000 ParentCid: 0f10
DirBase: bfa19900 ObjectTable: e669b630 HandleCount: 11.
Take the process id from the output and run the following command. The following command shows the process flags. The output shows the flags as 144d0841 in the example for x64 and 0x44082d for x86.
0: kd> dt nt!_eprocess fffffa82fa924b30 flags
+0x440 Flags : 0x144d0801
0: kd> dt 89038a08 nt!_eprocess flags
+0x240 Flags : 0x450801
Run the ed command to edit the memory and set the process flags to mark the process critical. Adding the value 0x2000 marks the process critical.
0: kd> ed fffffa82fa924b30+0x440 0x144d0801+0x2000
0: kd> ed 89038a08+0x228 0x450801+0x2000
Now close the debugger and proceed with the repro steps to crash or close the application.
In our case the test application with the code mentioned above should cause the machine to bugcheck as soon as any key is pressed.
The complete memory dump will contain the process information as well as kernel data for investigation.