How is procdump -t-dump used at process termination?

Question

The question may be a bit uncomfortable, but here is my detailed problem:

I am currently studying the configuration of sysInternals procdump.exe to monitor an application that detects false disappearances - the user reports that the application simply “left” without any trace after a short visible freeze of the application window.

My first idea was to run procdump -e -x . MyApp.exe procdump -e -x . MyApp.exe , which would write a crash dump when the application encounters an unhandled exception, but then I saw that there is also a -t switch, which is

-t - Write a dump when the process ends.

Automatically generates a dump when the process ends.

Now the problem

I tested the -t switch with our application by inserting an ExitProcess or TerminateProcess call in a specific place where I can run it.

So far, the application behaves as expected, i.e. TerminateProcess immediately "kills" the running application, and ExitProcess takes some time, because it performs a global cleanup, the dump generated in this way is useless in both cases.

The dumps I get for -t always only contain the sinlge thread (where the application ran more than 20 threads at the time of termination), and the column is not even in a useful place. (This is just one random thread from the completed application.)

Am I doing something wrong? Can I use procdump -t to track unexpected calls to process exit functions?

Answer 1

Can I use procdump -t to track unexpected calls to all process exit functions?

I think not and that's why: calc.exe test process

 CommandLine: "C:\Program Files\Sysinternals\procdump.exe" -t calc.exe 

I am trying to carefully assume that procdump is waiting for the calc.exe process handler to execute.

 0:000> kb ChildEBP RetAddr Args to Child 0017f2e0 77135e6c 75336872 00000002 0017f334 ntdll!KiFastSystemCallRet 0017f2e4 75336872 00000002 0017f334 00000001 ntdll!NtWaitForMultipleObjects+0xc 0017f380 76cbf14a 0017f334 0017f3a8 00000000 KERNELBASE!WaitForMultipleObjectsEx+0x100 0017f3c8 76cbf2c2 00000002 7ffdb000 00000000 kernel32!WaitForMultipleObjectsExImplementation+0xe0 0017f3e4 011c6135 00000002 0017f46c 00000000 kernel32!WaitForMultipleObjects+0x18 WARNING: Stack unwind information not available. Following frames may be wrong. 0017fc30 011c999e 00000003 013d1de0 013d1e78 procdump+0x6135 0017fc78 76cc1194 7ffdb000 0017fcc4 7714b495 procdump+0x999e 0017fc84 7714b495 7ffdb000 77ad79b5 00000000 kernel32!BaseThreadInitThunk+0xe 0017fcc4 7714b468 011c99f5 7ffdb000 00000000 ntdll!__RtlUserThreadStart+0x70 0017fcdc 00000000 011c99f5 7ffdb000 00000000 ntdll!_RtlUserThreadStart+0x1b 0:000> dd 17f46c 0017f46c 00000238 00000268 0:000> !handle 238 f Handle 238 Type Process Attributes 0 GrantedAccess 0x1fffff: Delete,ReadControl,WriteDac,WriteOwner,Synch Terminate,CreateThread,,VMOp,VMRead,VMWrite,DupHandle,CreateProcess,SetQuota,SetInfo,QueryInfo,SetPort HandleCount 5 PointerCount 52 Name <none> Object Specific Information Process Id 1580 Parent Process 2476 Base Priority 8 

In the crash dump file, the last process stack terminates (TID 3136) immediately before the process terminates.

 0:000> ~ . 0 Id: dc8.c40 Suspend: -1 Teb: 7ffdd000 Unfrozen 0:000> .formats c40 Evaluate expression: Hex: 00000c40 Decimal: 3136 

An emergency dump file is created after the end of the last thread and before the end of the process.