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

Question

The question may be a bit awkward, but here's my detailed problem:

Currently I'm looking into setting up SysInternals' procdump.exe to monitor an application of ours that exhibits spurious disappearances -- that is, the user reports that the application is simply "gone" without any trace after a short visible hang of the application's window.

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

-t - Write a dump when the process terminates.

automatically generates a dump when the process terminates.

Now the problem

I have tested the -t switch with our app by inserting a ExitProcess or TerminateProcess call at a defined location where I can trigger it.

While the app behaves as expected, i.e. TerminateProcess immediately "kills" the running app and ExitProcess takes a while because global cleanup is run, the dump generated this way is useless in both cases.

The dumps I get for -t always contain only a sinlge thread (where the app was running over 20 thread at termination time) and the callstack isn't even at a useful location. (It just seems to be one random thread from the terminated app.)

Am I doing something wrong? Can I usefully use procdump -t to track down unexpected calls of process exit functions at all?

Answer 1

Can I usefully use procdump -t to track down unexpected calls of process exit functions at all?

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

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

I try to carefully suggest that procdump is waiting on calc.exe process handle.

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 gets stack last complete process thread (TID 3136) just before the end of the process.

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

Crash dump file is created after the completion of the last thread, and before the end of the process.