Print this page
Wednesday, 14 August 2019 20:36

The Case of Changing Default Printer

Written by
Rate this item
(0 votes)


While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s something rewarding about quickly finding a solution. In the process, I often end up with an idea for a blog post I can share with thousands five regular readers. A couple of weeks ago I helped a customer solve a particularly weird case: the "legacy" printer management (meaning that Windows will not manage the default printer) was enabled and yet - for some reason - the default printer kept changing for end-users to "Microsoft Print to PDF". Obviously something was broken so I had to investigate.

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!

Read 5766 times Last modified on Thursday, 15 August 2019 11:16