fix(crashpad): capture a real CONTEXT for the immediate dump

[Rakdos8]

Summary

One fix at the crash-reporting entry point (1 atomic commit).

Problem

CrashpadCrashInterface::ProduceImmediateDump zero-initialised LPCONTEXT to null, passed it to GetThreadContext and dereferenced it — a guaranteed crash in the crash-reporting path.

Fix

Capture the calling thread's context with RtlCaptureContext and pass a real CONTEXT to DumpWithoutCrash.

Type

Guaranteed crash in the crash-reporting path (Critical).

Testing

Manual review; Win32-only path, behaviour for the legitimate case preserved.

Note

An earlier revision of this PR included a second commit reframing the LoadLibrary("kernel32") call in SetProcessAffinity as a DLL search-order hijack. As @neptuwunium pointed out, that framing was wrong — kernel32 is a KnownDLL, resolved from \KnownDlls, so the unqualified name is not a hijack vector. That commit has been dropped.

[neptuwunium]

kernel32.dllcannot be hijacked because it is always loaded and a known DLL, which means that it is returned before searching the DLL paths.

LoadModule and GetProcAddress both are kernel32 functions so I don't know why it is loading it to begin with, SetProcessAffinity and SetProcessAffinityMask both exist since Windows XP and can be called freely without doing any dll loading.

Note: I am not a maintainer or an employee of Fenris Creations.

[Rakdos8]

kernel32.dllcannot be hijacked because it is always loaded and a known DLL, which means that it is returned before searching the DLL paths.

LoadModule and GetProcAddress both are kernel32 functions so I don't know why it is loading it to begin with, SetProcessAffinity and SetProcessAffinityMask both exist since Windows XP and can be called freely without doing any dll loading.

Note: I am not a maintainer or an employee of Fenris Creations.

You're right on both counts - thanks for the catch.

I'd convinced myself the unqualified LoadLibrary("kernel32") was a search-order vector and missed that kernel32 is a KnownDLL: pre-mapped from \KnownDlls and returned by base name before any path search ever runs. The "hijack" framing was wrong.

Your second point is the cleaner one anyway : SetProcessAffinityMask has been in kernel32 since the earliest Win32, this binary already requires Windows 10, and LoadLibrary / GetProcAddress are themselves kernel32 exports, so the dynamic resolution wasn't buying any backward-compat coverage either. A direct call would be the right answer.

I've dropped that commit from the PR rather than reframing it as cleanup : it didn't belong tied to a retracted security claim. It can land separately if a maintainer wants the cleanup. The PR now contains only the Crashpad immediate-dump null-deref fix.

Maintainer or not, the technical points stand. Appreciated.

[CCP-Aporia]

Hi @Rakdos8

Thank you for the PR and apologies for the late response. We are still in the process of sorting out some details around contribution guidelines and PR templates.

That said, this is a good find, addressing a real problem with capturing a thread context when using ProduceImmediateDump(). I will get back to you once we are in a position to accept contributions.