Thanks for taking the time to look into this. Certainly case 4 should be possible to remove. We can call IsUser32AndGdi32Available which is in the same namespace to check if Win32k is disabled then just not call it, although from a correctness perspective I don't see why we should do as we're handling the error correctly which would manifest if win32k is disabled. However the rest are going to be difficult. This is fundamentally a problem with Windows as it stands, Windows is not designed to be used with general purpose code which disables win32k. 

Even if we completely eliminate all direct calls as we can see transitive dependencies sneak in due to the Windows' design. For example even if we're not using COM's cross-apartment features, perhaps we just want to call StringFromIID, the COM runtime will still pull in USER32 in case it needs to set it up in the future and this causes a chain reaction to initialize GDI etc. This is why Chrome has to hook GdiDllInitialize and a few other functions to ensure GDI32.DLL doesn't fail at startup preventing many APIs and process initialization from failing.

In an ideal world the user-mode DLLs would be fully aware of win32k disable and act accordingly, however I think that's unlikely to happen. Now that most (all?) system calls actually dispatch through win32u.dll I wonder if a stub version of that library could be created which is loaded by the loader if win32k is disabled. Perhaps the library could even lie about the results of a few APIs (such as those that GdiDllInitialize depends on) to make the process initialize even in the presence of transitive dependencies.

Realistically though, Chrome's use of win32k disable pre-dates the introduction of auditing for this event. I'm not convinced that outside of an actual auditing scenario by the developers this logged event provides any value to the end-user, they can neither block its logging, or remediate it, and therefore the solution would be stop logging this event unless an auditing bit was set. I guess the rationale was it could be used to detect if your were being exploited? The latest documentation for PROCESS_MITIGATION_SYSTEM_CALL_DISABLE_POLICY clearly shows an additional auditing bit (although it's not documented what it means, see https://docs.microsoft.com/en-us/windows/desktop/api/winnt/ns-winnt-_process_mitigation_system_call_disable_policy) which Chrome does not set. In any case we normally enable win32k disable at process creation using the PROCESS_CREATION_MITIGATION_POLICY_WIN32K_SYSTEM_CALL_DISABLE_ALWAYS_ON mitigation policy, which does not have a documented (or undocumented) way of enabling or disabling the audit policy as far as I can tell.

It's worth noting as a final point that we've had crashes in the past where Chrome code has clearly taken the path that Win32k is enabled, then called an API which fails almost certainly because it's actually disabled. The only explanation we can come up with is GetProcessMitigationPolicy is failing or returning the invalid state of win32k disable, perhaps due to third-party interactions or app-compat behavior. Therefore in the past we've added code to check for win32k disable directly by calling a GDI/USER system call and inspecting the result (which exposes other problems with win32k disable) so if we did this we'd always trigger the audit log intentionally which seems sub-optimal.

As the issue seems to be out of scope for us to triage this further from our(TE) end, hence adding label TE-NeedsTriageHelp and requesting someone from respective team to have a look into this and help in further triaging.

Thanks!

Can somebody ask the Microsoft Edge security team to weigh in on this bug? They may be in the best position to recommend a path forward, perhaps a change in the auditing to reduce the noise.