Use GFlags to catch the silent killer (silent but deadly)


Suppose you have some process that is mysteriously dying and you can't figure out why. You think that some other process is doing a Terminate­Process but heck if you can figure out who that is.

Starting in Windows 7 and Windows Server 2008 R2, the GFlags tool will let you catch these miscreants.

On the Silent Process Exit tab, you enter the program you want to keep an extra eye on and check the box Enable Silent Process Exit Monitoring and select what you want to happen when one of these mysterious exits occurs. You can ask for an entry in the event log that identifies the killer, and you can ask for debugging minidumps to be created of both the killer and the victim.

Comments (22)
  1. Joshua says:

    For some reason, got no minidump for this one:

       mov RSP, 0x010000

       call whatever

    Thankfully the debugger was able to handle it.

  2. NotThisMind says:

    I was hoping for another code example of doing this from you but i guess this would be too complicated to do since it probably requires ring 0 hooks?

    Anyway, nice to know a program can do this.

  3. Cesar says:

    > Starting in Windows 7 and Windows Server 2008 R2, the GFlags tool will let you catch these miscreants.

    Unless said miscreant also kills the GFlags tool...

  4. Mark says:

    Cesar,

    The GFlags tool simply sets a few registry keys, so you could always set those in another way.

  5. Anonymous Coward says:

    Cesar: As Mark already said, you use the GFlags tool to modify registry keys. After that, GFlags doesn't need to run anymore. I guess the miscreant could manually remove the registry keys, but that required administrative privileges. If the miscreant has those, you're screwed anyway.

    The functionality that can be configured with GFlags is really, REALLY awesome, not just silent process exit. I have turned on most of the features for every program I'm developing and it helps a lot.

  6. alegr1 says:

    @Joshua:

    Minidump is invoked by the unhandled exception handler in the crashing process. Such handler needs to have a valid stack.

  7. Myria says:

    Does this work for __fastfail in Windows 8/8.1/10?

  8. Cesar says:

    @alegr1: do you mean Windows doesn't have something like sigaltstack?

  9. Gabe says:

    I'm curious as to whether this works to catch a double fault. Every so often a program window will disappear, and I tend to attribute it to a double fault, but it would be nice if this could tell me for sure.

  10. alegr1 says:

    @Cesar:

    An external debugger can handle such faults. Windows doesn't have signals. A default reserved stack size is 1 MB. Why bother with sigaltstack?

  11. Cesar says:

    @alegr1: To be able to do the Windows equivalent of a core dump in case of runaway recursion, which is when the stack is guaranteed to be exhausted?

  12. Joshua says:

    Sigstack is for weaklings. Real men put the old IP in the single reserved slot at the top of the stack and jump to the handler with SP still out of bounds.

    /sarcasm

  13. alegr1 says:

    @Cesar:

    Full process dump is done by an external program (DrWatson or its current equivalent).

  14. Jon says:

    What are the performance implications of GFlags settings? Is it ok to run them in production?

  15. Mark says:

    Gabe: almost always stack exhaustion.

  16. AshleyScirraLtd says:

    Your 'suggestion box' doesn't accept comments any more, so sorry to off topic make a suggestion but:

    Regarding blogs.msdn.com/.../3926581.aspx, could the limit of 10,000 window handles per process be increased in 64-bit Windows?

  17. Kyte says:

    @AshleyScirraLtd

    a) If the Suggestion Box is closed then it means Raymond is not open to suggestions.

    b) That's not something that Raymond has any control over.

    c) Why on earth would you need more than 10k window handles.

  18. Sushanth says:

    I don't think this works when the process was killed through a TerminateProcess call instead of a ExitProcessCall. My recollection my be off but a few months ago I had to deal with a process killing my process and all I saw in my process was I am happily executing an innocent instruction and then next instant my process is dead and debugger has no where to go. There was no code executed in my process before its death.

  19. Gabe says:

    Sushanth: The whole point of this post is to find out who called TerminateProcess on you!

    Mark: Yes, that's my guess. I'm wondering if this tool will tell me whether I'm right.

  20. cheong00 says:

    I hope I did learn about this before I leaved one of my ex-company. They have started migrating to Win7 at the time, and has a multithread DCOM server process that sometimes just disappeared silently. The C++ team think probably one of the bugs killed it but have no idea where the bug was.

  21. ANon says:

    @Kyte

    @AshleyScirraLtd

    But Raymond already responded to C using his psychic powers:

    C) "Programs shouldn't be creating anywhere near ten thousands window manager objects in the first place."

  22. Mike Dimmick says:

    @AshleyScirraLtd: I may be speaking out of turn, but I think that ship has sailed. Win32 is in legacy maintenance mode and will stay that way. Windows Runtime does not use window handles and does not have this problem.

    It hasn't been announced yet, but I fully expect that the major change to the API surface in Windows 10 is that Windows Runtime will be able to create and manage resizable overlapping windows. Welcome to Windows 2.0 ;)

Comments are closed.

Skip to main content