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?

Crosslink to Sysinternals Forum entry: http://forum.sysinternals.com/topic28976_post138272.html#138272 — Martin Ba, Jan 14 '13 at 15:06
I know that GFlags can capture a dump when a process ends. It is available for free from Microsoft as part of the Debugging Tools for Windows. You can find that free software package here: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx Under its Silent Process Exit tab, you can set it to capture dumps as well as create dumps for a specified image (application) whenever it runs or just under certain conditions. It may be more useful to you. — StarPilot, Jan 14 '13 at 19:51
@MartinBa did you ever find a good tool for this or the reason why the application is suddenly gone? — nietras, Jun 28 '18 at 20:36
@nietras not really. Spurious disappearances got a lot less problematic once all customers switched away from Win XP. If, as was the case here, you suspect a rogue `TerminateProcess` call, maybe some API hooking could help. — Martin Ba, Jun 28 '18 at 20:41

Serg · Accepted Answer · 2013-01-14T19:42:39.743

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

enter image description here

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

enter image description here

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

enter image description here

Very useful research! But what I don't get is ... if procdump "just" waits on the process handle, wouldn't the process be completely gone once it gets notified on its wait? The process has to be gone for the Wait to be fulfilled, or has it not? — Martin Ba, Jan 14 '13 at 20:27
I'm not sure about that results is waiting on process handle so I wrote that trying to carefully suggest it. Procdump also waits on debugevents. The result with `-t` switch is creating dump file after last thread exits and befor process exits like in screenshots. — Serg, Jan 15 '13 at 10:33
Thanks for this update. May I ask what tool did you use to trace the events shown in the last two screenshots? — Martin Ba, Jan 15 '13 at 11:53

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

Now the problem

1 Answers1