Black screen with cursor during imaging.

[Garacesh]

This is only happening on one of my test machines so far, but it hasn't happened on this machine previously.

 

It's exactly what it says on the tin, I guess. During imaging, I'll PXE boot the machine into WDS and let it do its thing. When the machine then reboots after installing the Operating System, it hangs on a black screen with just a mouse pointer for a while. The mouse pointer is responsive to movement, and there's no way to log-in (as there's no login screen and typing credentials does nothing).. After a while (~20 mins?) I finally get the login screen which automatically logs in as the local admin and continues the LiteTouch installation.

 

The only thing I can find on the internet is people suggesting Windows is picking up multiple screens, but since the mouse pointer is responsive I can determine that isn't the case as it never leaves the edges of the current screen.

 

So what gives? Anyone else having this? Could it just be a bug with displaying the "We're setting things up for you" lark...? Edit: This black screen happens after the setting-things-up stuff.

Edited June 23, 2016 by Garacesh

[BarryBKS]

At what point of the install does this occur?

 

Has the machine already restarted once and installed drivers, showing the 'Getting Ready' message?

 

If so, then you may have some logged errors in your Event Viewer which may help identify the problem.

 

I have encountered the black screen with a working cursor after a completed install, but not during the image process.

 

Let me know what you find.

 

Cheers.

[Garacesh]

At what point of the install does this occur?

 

Has the machine already restarted once and installed drivers, showing the 'Getting Ready' message?

 

If so, then you may have some logged errors in your Event Viewer which may help identify the problem.

 

I have encountered the black screen with a working cursor after a completed install, but not during the image process.

 

Let me know what you find.

 

Cheers.

 

Bump, almost a year later. Getting ready to prep W10 again and hitting the same snag. Most of the time the machine will reboot after a while and finish setup as normal. Rarely, the machine doesn't.

 

So, the process goes a little something like this:

1. The machine boots into WDS
   
2. Login, assign machine name, select optional applications etc. Begin setup.
   
3. Lite Touch Installation (Running action: Inject Drivers, Apply Patches, Install Operating System) runs fine.
   
4. Machine reboots.
   
5. Windows 10 logo, spinny dots, 'Getting devices ready ##%' then 'Getting ready'
   
6. Black screen with mouse pointer
   
7. Machine reboots
   
8. More spinny dots
   
9. W10 full-colour setup screen (Finalizing your settings, bigger spinny dots)
   
10. "Hi", "We're happy you're here", "Getting things ready, please don't turn off your PC" etcetera, etcetera.
    
11. Finally, black screen with (still fully-responsive) mouse pointer.
    

 

It's like it's just failing to reboot after the initial setup.

 

If I force the machine to power down, then switch it on again, everything proceeds as normal with the imaging. I get a black screen (with no mouse pointer), spinny loading dots, before it goes to the standard Windows startup screen (Apply Group Policy, Installing Managed Software, waiting for Local Session Manager), then it logs in as the local admin account and continues the Litetouch installation where it left off (Running Action: Gather local only, Post-Apply Cleanup, Recover from Domain, Tattoo, etc)

 

Only thing that looks out of place in the Event Viewer are some WHEA-Logger Errors.. "A fatal hardware error has occurred. Reported by component: Processor Core. Error source: Machine Check Exception. Error Type: Cache Hierarchy Error. Processor APIC ID: 0"

Edited May 19, 2017 by Garacesh

[BarryBKS]

The only item I can think of is if you are applying patches from WSUS during the image build?

 

One of these patches could be the cause of your black screen.

 

A long winded test would be to apply the basic image to a machine or VM, without the patches and then patch it manually after the image has finished.

 

If you don't get the black screen during the deployment, but you do get it after the patching, then that is defiantly the issue.

 

I patch my image and capture it back to WDS for deployment. This applies an up-to-date image and reduces the black screen from reoccurring.

 

Hope that's of some help.

 

Barry.

[Garacesh]

Not actually using any patches at all (the 'Applying Patches' stage doesn't actually do anything, it's just up there for a fraction of a second). Just a stock images downloaded from VLSC, combined with drivers (added to the Out-Of-Box drivers section) and applications (which it happens even if I don't install any applications)

 

We don't use captured images because I could never get SysPrep to work, and it seems a waste to have an image per machine when they're all just stock anyway. Group Policy, SCCM and mandatory profiles take care of the rest.

Edited May 19, 2017 by Garacesh

[ReadTheNetwork]

Could it be to do with the graphics driver?

[Garacesh]

Could it be to do with the graphics driver?

 

I'm doubtful.

I've (I think*) disabled drivers for all the other machine types, and then disabled graphics drivers for this machine type, and it's still getting stuck on the black screen.

Just going to keep disabling drivers until it (hopefully) works, might give me some indication of what's going on.

 

* If I disable a folder, but don't disable its subfolders, are the drivers in the subfolders still enabled?

Root folders (HP 630, HP Compaq Elite SFF PC etc) have 'Enable this folder' unticked, but their subfolders (Intel iGFX, Realtek Audio, etc) don't.

[Arthur]

Finally, black screen with (still fully-responsive) mouse pointer.

There seems to be an issue with 1703 and language settings/language packs that cause Windows to hang near the end of the setup process. Could it be related to that perhaps?

 

https://sccmentor.com/2017/05/20/windows-10-1703-language-pack-fun-and-games/

 

OK, if you have read Damon’s blog post then I hope you have taken note of the following:

 

• A screen asking if I wanted to join my work network in the form of mydomain.com.au
  
• A screen asking what sort of display language I wanted to choose
  
• Display language not being set correctly – AGAIN!
  

I suffered from all these woes along the journey but I can also add the following to the list, a couple of things that Damon didn’t get:

 

• Win 10 hanging on the the ‘Just a moment’ screen indefinitely after a build
  
• An error message ‘Oops something went wrong’ after the build had completed, which I was then allowed to skip past.
  

Note that the above two errors can be rectified by reintroducing the deprecated SKIPMACHINEOOBE and SKIPUSEROOBE tags in your unattend file. These settings are not recommended for production devices, however we have little choice but to use them on the current 1703 media. More on how to add those later.

[ReadTheNetwork]

Are you able to boot in safe mode? If so maybe review the event logs in safe mode? Or the build logs during deployment?

[Garacesh]

There seems to be an issue with 1703 and language settings/language packs that cause Windows to hang near the end of the setup process. Could it be related to that perhaps?

I don't think so. I'm using Windows 10 Enterprise LTSB 2016 x64. According to this page, 1703 wasn't made available outside of Windows Insiders until April this year. So it looks like we're on 1607

 

Are you able to boot in safe mode? If so maybe review the event logs in safe mode? Or the build logs during deployment?

I manually restarted the machine and let it finish imaging, all I could see was the errors mentioned before (WHEA-Logger: "A fatal hardware error has occurred. Reported by component: Processor Core. Error source: Machine Check Exception. Error Type: Cache Hierarchy Error. Processor APIC ID: 0")

This machine has hanged yet again, so I've done a manual restart and I'll let it finish, then try and find any logs.

[Michael]

We don't use captured images because I could never get SysPrep to work, and it seems a waste to have an image per machine when they're all just stock anyway. Group Policy, SCCM and mandatory profiles take care of the rest.

 

Not running Sysprep isn't going to help - I suspect this is the source of the problem. Even on identical spec machines it can cause issues if you don't run it.

[Garacesh]

Not running Sysprep isn't going to help - I suspect this is the source of the problem. Even on identical spec machines it can cause issues if you don't run it.

 

Could you elaborate?

 

To my knowledge, Sysprep is only needed if you're capturing an image, which we aren't doing. We're just using WDS to slap a stock iso (with no OOBE etc) onto a machine, and letting WDS install the drivers the machine needs (from Out-of-box Drivers). Group Policy then takes care of the vast majority of our software, with things like SIMS being done manually from the Solus3 Server.

Edited May 22, 2017 by Garacesh

[Michael]

Apologies I overlooked that. If deploying just an unmodified ISO then yes that would work. In a real life situation no; much better/quicker to capture the latest update on the core image first.

[ReadTheNetwork]

Apologies I overlooked that. If deploying just an unmodified ISO then yes that would work. In a real life situation no; much better/quicker to capture the latest update on the core image first.

 

I would agree, my image contains Windows and the updates, no software. The updates then gets installed on the wim file offline so the image is kept up to date with the updates, saving time.

 

But on another note, I'd try disabling all drivers, then test that.

 

The only time I've had a black screen is either driver issue or HDD/RAM fault.

[Garacesh]

I would agree, my image contains Windows and the updates, no software. The updates then gets installed on the wim file offline so the image is kept up to date with the updates, saving time.

Interesting. I couldn't get updating the WIM working either. Just always ended up with errors in some fashion (though at this point I can't recall what they were.)

Our updates are installed via our SCCM server as part of the imaging process. Interesting how these things get achieved through different methods.

 

I'm going to try rebuilding the deployment share overnight, it takes a couple of hours so there's no sense doing it yet. If that doesn't work I'll disable everything and see what happens.