How to electrify your own fence: ProcessStrictHandleCheckPolicy


During process termination, if you try to enter a critical section that is owned by another thread that has already been terminated, the gates are now electrified, and the kernel simply terminates your process.

We saw that an invalid handle error and an object type mismatch error both mean that your critical section is corrupted.

And as noted in a comment on the last linked article, there is an option (enabled by default for Store apps) to electrify the fences and raise a exception if an application tries to use an invalid handle or an invalid type of handle (for example, trying to Set­Event on a semaphore). Classic Win32 applications can opt into this behavior by calling Set­Process­Mitigation­Policy and asking for the Process­Strict­Handle­Check­Policy to be turned on.

Comments (13)
  1. kantos says:

    Definitely worth turning on while debugging or running tests, and probably worth turning on all the time if you're reasonably confident you've found any issues.

  2. SimonRev says:

    Wish I had that for Windows CE. I just spent forever debugging a problem where someone had written code like:
    DWORD waitResult = WaitForMultipleObjects(2, events, false, 12);
    if (waitResult == WAIT_OBJECT_0) { return; } // Thread exit signal
    if (waitResult == WAIT_TIMEOUT) { throw fooErr; } // Other thread got gummed up. Punt to higher level error routine then terminate
    // If we get here, then we got the signal we are expecting.

    Of course, they had forgot to actually create the second event, so WaitForMultipleObjects was returning WAIT_FAILED instead. Crashing and burning would have been very helpful here. Especially since most of the time the other thread was extremely fast so normally the WaitForMultipleObjects would just fall through, but very rarely odd "impossible" states would show up when this thread would merrily carry on while the other thread was still processing.

  3. Douglas says:

    So how many things that hook in (e.g. antivirus, printer drivers) does this break?

    1. Darran Rowe says:

      I would be surprised if it broke anything at all.
      This basically terminates the process if things break during process exit, and it would be the same as if you had access violations or even an explicit call to TerminateProcess during process exit.
      So basically, when a process goes to cleanly exit, the state becomes a landmine anyway. These things would have to already deal with the fact that during exit, the process could just terminate since access violations and calls to TerminateProcess can happen. So these things must already deal with surprise cleanup regardless.

      1. Michael says:

        This isn't just at shutdown, it's any usage of invalid handle at any time (I can't seem to reproduce invalid type of handle):
        #include
        #include
        int main() {
        PROCESS_MITIGATION_STRICT_HANDLE_CHECK_POLICY strictHandleCheck = {};
        strictHandleCheck.RaiseExceptionOnInvalidHandleReference = 1;
        strictHandleCheck.HandleExceptionsPermanentlyEnabled = 1;
        if (!SetProcessMitigationPolicy(ProcessStrictHandleCheckPolicy, &strictHandleCheck, sizeof(strictHandleCheck)))
        return 1;
        putchar('.');
        HANDLE sema = CreateSemaphoreW(nullptr, 1, 1, nullptr);
        if (sema == nullptr)
        return 2;
        putchar('.');
        SetEvent(sema);
        putchar('.');
        CloseHandle(sema);
        putchar('.');
        SetEvent(sema);
        putchar('.');
        getchar();
        }
        I get four dot's and a crash (after tcalling SetEvent on a closed handle): getchar() never gets called. The first SetEvent does return false, it's just not crashing for me.

        1. Darran Rowe says:

          My misunderstanding there, but the thing is, these have to also work for Windows Store apps, especially the user mode graphics driver component. As stated, this is on by default in store apps too.

    2. Darran Rowe says:

      Also, beginning with Windows Vista, the kernel started doing this kind of thing anyway, as said in the first link. So anything that hooks in must already have to deal with this situation.

    3. smf says:

      >So how many things that hook in (e.g. antivirus, printer drivers) does this break?

      I don't have an intimate knowledge on what virus checkers or printer drivers do that could be affected by this.

      But it's a per process flag. So if you enable it and someone injects code into your process that accesses an invalid handle, then you will get killed. But it shouldn't affect their process at all, so really it doesn't break them. It breaks you.

      1. Douglas says:

        Right, that's what I meant. It breaks their code which, being in your process, breaks you.

        So if your code enables this, there might be customers' machines out there where you crash. So, like LARGEADDRESSAWARE, NXCOMPAT, and HIGHENTROPYVA, your code might be correct, but you crash anyways.

        Here's one where Windows Presentation Foundation dies that I actually ran into: https://connect.microsoft.com/VisualStudio/feedback/details/807331/access-violation-in-penimc-dll-for-wpf-apps-built-with-highentropyva-on-windows-8-touchscreens
        I don't mean to name and shame, just to say that these things can break in a way that means you can't use the cool new feature.

  4. Myria says:

    I would never enable ProcessStrictHandleCheckPolicy for anything but debug builds, thanks to the zillions of buggy third-party DLLs that get loaded into our process. For example, the user-mode parts of graphics drivers, anti-virus software, etc.

    I wish "terminating the process" weren't the only option for a lot of these errors. We want to have our own crash reporting program, and not have to wait for two weeks while Microsoft processes our crashes via Windows Error Reporting. Our crash handler handles a lot of things, but can't handle anything in kernel32 or ntdll that does a __fastfail.

  5. Joshua A. Schaeffer says:

    If you didn't make these posts, many of us would have never ever learned about this functionality. Is there a page that clearly shows the Win32 API changes in each new Windows 10 version, or does it come down to a diff on dumpbin?

    1. Mike Diack says:

      Great comment from Joshua. Is there an index page showing new/change APIs for each Windows release? would be incredibly useful

    2. Simon Clarkstone says:

      Also: is there a list of all these strict modes that Windows API users can turn on? I want to catch things like that as soon as possible in the development cycle.

Comments are closed.

Skip to main content