Struggling with Windows 11 upgrades? You’re not alone. A hidden culprit in legacy Group Policy Objects (GPOs) could be causing unexpected failures – and even dreaded blue screen of death (BSOD).
I recently kicked off a Windows 11 in-place upgrade for a customer looking to uplift their Windows 10 fleet before EOL on 14 October 2025. With the deadline fast approaching, we agreed not to rebuild the entire SOE.
Instead, we opted to upgrade existing devices to Windows 11 while layering on new security features and hardening policies.
Bare metal build? Done and tested. Time to build out the in-place upgrade.
We reused a proven approach: a pre-cache task sequence to download content and run all pre-flight and compatibility checks.
Once the pre-caching and compatibility steps passed, we triggered the in-place upgrade, wrapped in a PSADT launcher.
Testing on VMs and even physical test devices went off without a hitch. So, we green-lit a pilot deployment.
That’s when things went sideways.
The BSODs begin
As soon as the upgrade reached 100% and the device rebooted to finalise, we started seeing the dreaded INACCESSIBLE_BOOT_DEVICE BSOD. No rollback. No repair. Just an endless loop of failure.
We scoured forums. Found threads about Dell issues. Fixes ranged from disabling virtualisation to turning off Secure Boot. None of them worked.
What made it worse? Our test devices kept passing. Only the pilot users were crashing.
We booted into recovery media and dug into setupact.log and setuperr.log. Nothing. Setup completed cleanly.
We rolled back to 23H2. We tried a fresh 24H2 ISO. Mixed results.
Then we made a discovery buried in the setup.dev.log file:
!!! pol: [-] Restricted setup class of selected driver: !!! pol: !!! dvi: Installation of device is blocked by policy!
The real problem: A legacy group policy
Deep in the old Windows 10 GPOs was a policy:
‘Prevent the installation of devices using drivers that match these device setup classes’
And here’s what it was blocking:
- 50127dc3-0f36-415e-a6cc-4cb3be910b65 – Processors
- 4d36e97b-e325-11ce-bfc1-08002be10318 – SCSI Adapters (NVMe, RAID, SCSI) — listed twice
- 4d36e96a-e325-11ce-bfc1-08002be10318 – Hard Disk Controllers
No idea why these were being restricted for standard workstations. But that GPO blocked the very drivers Windows needed to stage during the upgrade. Because the install happened offline, no errors were logged. But once the system switched into online mode to boot. BSOD.
Even worse? That setting was duplicated across multiple policies going back over a decade.
We excluded those policies from the Windows 11 OU. Problem solved. Devices upgraded with user downtime under 10 minutes, no issues.
Key learnings
- Regularly audit your Group Policy infrastructure to ensure policies remain relevant and up-to-date.
- Use major Windows upgrades as an opportunity to start fresh with a clean set of policies.
