While working on my GflagsX tool, there was yet another feature the tool was missing compared to the classic GFlags tool – Silent Process Exit support. But what is Silent Process Exit?
According to the documentation there are two scenarios that trigger Silent Process Exit:
- Self exiting – one of the threads in the process calls ExitProcess.
- A TerminateProcess call is issued from another (or the same process).
The documentation states that if a process exits because all threads terminate normally, then Silent Process Exit is not in effect. (also if kernel code kills a process, Silent Process Exit is not invoked).
The documentation may lead us to belive that if a process exits normally (no abnormal termination or exception) then Silent Process Exit will not be invoked. Let’s test that theory.
First, let’s configure Silent Process Exit with GFlags. (GFlagsX support is on its way). Run GFlags and select the Silent Process Exit tab:
Let’s test it with notepad. Type notepad.exe in the Image text box and press Tab. Some of the options light up. Let’s try something simple – generating a dump file when notepad terminates. Check Enable Silent Process Exit Monitoring and then set a dump folder location and dump type, like so:
Click Apply to apply the settings. Now launch Notepad. If you terminate it using (say) Task Manager, you’ll find a subfolder under the configured Dump Folder Location named Notepad.exe-(PID xxxx)-yyyyyyyy where xxxx is the terminating process ID and yyyyyy is the value returned from GetTickCount at the time of the exit (the number of milliseconds elapsed since Windows booted). Inside the folder you’ll find the dump file itself.
However, if you launch notepad again and just close its main window, you’ll find, perhaps surprisingly, that yet another folder was created with a new dump file. But why? Isn’t this a normal process termination?
Since we can be pretty sure no process (including notepad) called TerminateProcess, this means notepad called ExitProcess. Is this “normal”? Are there processes that terminate by just ending all their threads?
Let’s launch another notepad instance and attach WinDbg to it. Break into the debugger and add a breakpoint for ExitProcess:
0:000> x kernel32!ExitProcess* 00007ffe`1509b190 KERNEL32!ExitProcessImplementation (<no parameter info>) 0:000> bp KERNEL32!ExitProcessImplementation
Now let the process go and close notepad’s window. The breakpoint should hit:
Breakpoint 0 hit KERNEL32!ExitProcessImplementation: 00007ffe`1509b190 4883ec28 sub rsp,28h
Let’s look at the call stack:
0:000> k # Child-SP RetAddr Call Site 00 000000a1`4294f718 00007ffe`17119ce5 KERNEL32!ExitProcessImplementation 01 000000a1`4294f720 00007ffe`1711a345 msvcrt!_crtExitProcess+0x15 02 000000a1`4294f750 00007ff7`ffef934a msvcrt!doexit+0x171 03 000000a1`4294f7c0 00007ffe`15093034 notepad!__mainCRTStartup+0x1b6 04 000000a1`4294f880 00007ffe`17281461 KERNEL32!BaseThreadInitThunk+0x14 05 000000a1`4294f8b0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
Now it seems clear: when the first (“main”) thread of notepad returns from its main function, the C-runtime library calls ExitProcess explicitly. And in fact this is what you’ll find with most executables. This is why when the main thread exits in a C/C++ application, the process ends wven if other threads still exist and executing. From the Windows kernel’s perspective, there is no “main” thread – all threads are equal.
Silent Exit Process support is part of NTDLL and the Windows Error Reporting Service. This is in contrast to tools such as ProcDump from Sysinternals that attaches a debugger to the monitored process and creates a dump file when it exits. To set it up, the global flag with the value 0x200 (512) must be set in the “Image File Execution Options” (IFEO) subkey (just like all other global flags). However, once the bit is set, the actual details need to be written into the key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SilentProcessExit\notepad.exe. This is done on an image name basis just as with the IFEO key. Here is the example for notepad just shown:
Stay tuned for more info on Silent Process Exit support in GFlagsX!
Pavel Yosifovich 