The first step in my analysis was to reproduce the issue to see if it revealed any clues. For that, I verified that the customer enabled the "Turn off Windows default printer management" (under User Configuration\Administrative Templates\Control Panel\Printers) policy.

Then, I went to a Windows 10 machine, opened the printer management, verified that the setting ensuring that Windows will not manage the default printer was enabled, set the default printer and ran gpupdate /force.

To my consternation, the default printer changed to "Microsoft Print to PDF". I also noticed that the "Let Windows manage my default printer" checkbox briefly flashed when gpupdate ran in the background. I re-ran gpupdate and after a brief moment the "Let Windows manage my default printer" checkbox got activated. I re-ran gpupdate one final time and Windows reverted back to the legacy printer management.

Now I was thoroughly confused. I had to look under the hood at registry activity associated with the printer management to see if that would reveal the reason why Windows wasn’t honoring the GPO's setting. I ran Process Monitor, configured the filter to include the HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\LegacyDefaultPrinterMode path and executed gpupdate. Then I stopped the capture and looked at what Process Monitor had collected.

The first hit was a RegDeleteValue by svchost.exe (it hosts the group policy process), followed by a RegQueryValue operation initated by the SystemSettings.exe (Immersive Control Pane), which resulted in NAME NOT FOUND error. The next hit offered the next clue: SystemSettings.exe set the "missing" registry value to zero, thus enabling modern printer management. Just a few entries later, svchost.exe set the LegacyDefaultPrinterMode value back to 1.

Aha! Now I was getting somewhere. The thing about the "Let Windows manage my default printer" policy is that it is actually not a policy setting, but a group policy preference, meaning it deletes the specified registry value before setting it again. I closed the SystemSettings.exe app and captured another trace. This time around Google Chrome messed around with the printer settings.

My next step was to review chrome.exe stack to get better visibility into what was going on.

In this particular case, the function RegistryMonitor::CheckAndNotifyDefaultPrinterChange in prncache.dll (Print UI Cache) at frame 10 invoked GetDefaultPrinter and GetLegacyDefaultMode in winspool.drv (Windows Spooler Driver) at frames 9 and 7, followed by SetLegacyDefaultMode at frame 6. This stack trace proceeds all the way into the kernel API, kernelbase.dll (Client-DLL for Windows NT-Basis-API), which calls into RegSetValue. I suspected that Print UI Cache hooked deep into different Windows processes and interfered with the ProcessGroupPolicyExRegistry operation in gpprefcl.dll resulting in a race condition and default printer settings changing with each group policy update.

At this point there was just one question left to answer: how to work around this issue? Together with the customer, we removed the policy setting and created a group policy preference registry key to configure the printer mode. Instead of applying it in the Replace mode, we selected the Update option. Next, we tested the change and, to our satisfaction, the default printer settings did not change. Case closed!