Windows 10 hangs at "Just a moment..." on Dell Latitude 5500
We just received a new batch of Dell Latitude 5500 notebooks. We currently have an array of other Dell notebooks and desktops (17 in all) that we image with various golden images all cloned from the same base image built in VMware. This image is in audit mode with no preinstalled software or drivers. We clone the image, boot the clone (the clone boots in audit mode), install software (no drivers or VMware tools are installed), sysprep with an unattend.xml file, and image the workstations. Drivers are injected at the end of the Partclone process using @george1421 's post install script - https://forums.fogproject.org/topic/11126/using-fog-postinstall-scripts-for-windows-driver-injection-2017-ed. We have found that keeping all drivers out of our images allows us to never have problems with deploying a workstation, until now.
The new Latitude 5500 notebooks hang at “Just a moment…” upon first boot (just after Partclone and the driver injection). We have never seen Windows 10 do this before. They seem to image just fine (after some UEFI PXE tweaking that @george1421 and @Sebastian-Roth helped me through on a previous topic), so we are not sure where to go from here. Any suggestions would be greatly appreciated.
@greichelt You can reply to this thread as long as its in the same concept as the title. Just be sure to tag me so I see it.
@george1421 Thanks, George. I think I’ve got it from here. You can mark this as solved. If I have further unforeseen questions or problems regarding this same issue, should I reply to this post, or open a new one?
. I got several prompts titled “Windows can’t verify the publisher of this driver software.” Manual install of the drivers
Ok that right there will cause the issue you describe. Its prompting for input on an invisible desktop.
There is a way around the “unknown publisher” error by turning off driver verification in the golden image and then turning it back on at the end of the setupcomplete.cmd file, but that is a bad hack. Its better to get solid drivers or remove the troubling drivers from the driver directory on the FOG server so they don’t cause problems on the deploy end.
@george1421 Looks like I got a horrible driver pack from Dell. I got several prompts titled “Windows can’t verify the publisher of this driver software.” Manual install of the drivers from this folder using device manager throws the error, “Windows encountered a problem installing the drivers for your device. Windows found drivers for your device but encountered an error while attempting to install them. The has for the file is not present in the specified catalog file. The file is likely corrupt or the victim of tampering.” I’ve been getting my drivers from here - https://www.dell.com/support/article/us/en/19/sln312414/dell-command-deploy-driver-packs-for-enterprise-client-os-deployment?lang=en and, so far, have never had an issue. This has been an awesome resource up until now. The pack I downloaded was the Latitude 5500 Windows 10 Driver Pack A05 (11/26/2019).
@george1421 I am going to attempt #2 now as i have to run out to a customer’s site now to do a VMware install. #1 will take more time than I have now. To provide some additional insight into what happens before and after I hard reset (because I just did it after letting the 5500 sit all night), when I came in this morning, the notebook display was black. Gesturing on the touchpad wakes up the display “Just a moment…”, so it’s not a freeze; it is responsive. Holding the power button for 15 seconds does a hard shutdown. After powering back on, I get “Just a moment…” for a few seconds then the annoying “Hi” and all the M$ crap that follows. I am then presented with a desktop (no request to logon, just the desktop with the expected icons). Trying #2 now.
So to me its not clear where its hanging during OOBE. If it was a driver issue, one would think that it would happen at the beginning of OOBE. Rebooting the system unexpectedly will throw an error on the reboot. Something about windows can’t continue, reboot to run setup or some nonsense like that. So with that said I would think it might be done with OOBE and maybe something in the setupcomplete.cmd, because that is the last thing OOBE does before the login prompt is loaded. So this is just a wild guess, but lets start the startupcomplete.cmd file started to execute, but got hung up before the pnputil or during the pnputil program was running. Rebooting the computer would then just bring you to the login prompt because OOBE was done.
So there is two ways to test this.
- Use a post install script to remove the setupcomplete.cmd file and see if it images without hanging.
- On a botched install, recopy the setupcomplete.cmd file and run it again using an elevated privileged account. See if it completes correctly.
I have seen (in earlier days), the pnptuil go to install an unsigned driver and pop-up with a dialog box saying its an unsigned driver and prompt the IT tech to accept this driver. Well the setupcomplete.cmd runs without a desktop so no one would be able to see the prompt or respond to it.
I also wonder if any of the log files in c:\windows\panther or where ever the unattend.xml file was would provide any help. I know it takes a masters degree to decipher the logs but they do tell you what was going on at the time.
I forgot to mention, a hard reboot allows the machine to boot into the OS, but SetupComplete.cmd does not run, so no drivers are actually installed (SetupComplete.cmd installs the drivers injected to C:\Drivers) and the workstation rename does not happen (a PowerShell script that gets called by SetupComplete.cmd).