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.