Black CMD window showing up during Windows 10 22H2 install?

T

Tannah

New Member
When installing windows 10 22h2 Image built using NTLite 2023.12.9552 (64-bit)
A black command prompt window that pops up, as its installing the Post Setup programs. Nothing appears in the CMD window it just sits there.
The problem is the window is interactable, if you mouse over it you can close it, or if you press some keys it will stop the install, which ruins the install.
The image install will finish without issue if it left alone.

I thought it was a program that was acting up, so I went though removing every Post Setup program one at a time, on the Windows image, and double checked they were all using the proper silent command /S and all that.
But the Black CMD window keeps appearing If I have any Post Setup programs installing?
This didn't happen on previous versions, that I had noticed atleast.

I noticed this issue as my cat walked on the keyboard as I was testing the image.

Anyone have any insight?
 
Some installers will launch another task or command while they're running. That's part of their setup.

What you're seeing is CMD shell's QuickEdit mode, where if you select the window and hit space – it pauses the window from scrolling. This causes the running program to stop and never finish.

Maybe you should share your preset (after removing any user passwords or license key), so we can guess which is the offending installer.
 
garlin said:
Some installers will launch another task or command while they're running. That's part of their setup.

What you're seeing is CMD shell's QuickEdit mode, where if you select the window and hit space – it pauses the window from scrolling. This causes the running program to stop and never finish.

Maybe you should share your preset (after removing any user passwords or license key), so we can guess which is the offending installer.
Click to expand...
Im testing my iso on a VM and when im installing the post-setup programs my mouse is invisible, is it normal or just a VM thing?
Also, where do i put the parameters for an specific post-setup programs? Im Trying to silently install office 2016 but i don't know where i need to use the parameters.
 
Post-Setup (Machine) commands are executed by SetupComplete.cmd, which runs in an OOBE phase where no user interaction is allowed. You sit watching a Window splash screen, until everything is done running. That's the way MS designed it for W10 & 11.

Your mouse and keyboard input (shift-F10) will disappear at designated points in the OOBE workflow.

If you're installing Office from the ODT, you must specify "Display Level=None" in the XML if executed in Post-Setup (Machine).

Please read the Office365 silent install thread:

Office365 Package and Silent Install

Prerequisites These are the following tools I used to accomplish a self-extracting Office 365 deployment for post install. You may use other tools if you're comfortable with them, I just found this process easier with the following tools: Office Deployment Tool (ODT) - download WinRAR -...
www.ntlite.com www.ntlite.com
 
Ok here's the XML file, I'm at a loss as the CMD window did not show up on previous Images that I've made.
 

Attachments

  • Auto-saved a6cc7536.xml
    26.2 KB
Firefox & Thunderbird MSI options /q and /passive are redundant.
XnView forum recommends "/VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-"

I've never used XnViewMP to know.,
 
garlin said:
Firefox & Thunderbird MSI options /q and /passive are redundant.
XnView forum recommends "/VERYSILENT /SUPPRESSMSGBOXES /NORESTART /SP-"

I've never used XnViewMP to know.,
Click to expand...
Interesting, I've removed XnView MP, Firefox, and Thunderbird from the Post Setup installation list, and it still does the same thing. The black CMD window pops up blank, hangs around for a bit (maybe a minuet or so), then goes away and brings you to the local user setup screen.

The CMD window hides the mouse cursor but its still there, and active. thus if the mouse is sitting in the wrong area and is clicked, or keys are pressed on the keyboard (as some might be prone to do as it can appear to be non resposive as its just sitting there) the install often will fail.

If I remove all the programs from the post setup the blank CMD window does not appear at all, and it just goes on to the local user setup.

I use the /passive and /q options, as older versions of Firefox would still show dialogues and menus on the /passive switch, you just couldn't interact with the dialougs. I assume this has been solved?

I have older NTlite edited images of windows 10 22h2 that install the same stuff, but do not show the black CMD window.

Again the image will install, as well as the Post Setup programs.
The oddity is the Empty CMD window thats appearing and hangs around for a minuet or so. which can make it look like the install hanged.
If my cat had not jumped up on the keyboard, I would have just found the empty CMD window odd, but it turns out its user interactible.
 
Same issue here. Since i updated NTLite from 2023.6.9292 to 2023.12.9552, a black CMD screen is appearing instead of what i expected to be a background execution of Post-Setup (Machine). I am fairly certain this has to do with NTLite update.

garlin
Thanks for your suggestions on silencing the installers, but i think they have nothing to do with our issues. At least in my case it is the main CMD script that gets visible now with 2023.12.9552. Not the installers which are then called by that main script - the installers remain perfectly silent as they were. Could it be somehow related to an upgrade in 2023.8.9402? From changelog:
UI: Unattended page moved from Automate to Configure, Post-setup page moved from Automate to Integrate, in preparation for the upcoming feature
 
The only recent change to Post-Setup was to allow OEM PC's to work the same as non-OEM PC's.

MS has very strict guidelines for OEM's (PC manufacturers and resellers); in exchange for volume licenses, they must follow specific rules on how to deploy non-Windows "crapware" in their customized images. When Windows detects the presence of any OEM product key in the BIOS, it skips running SetupComplete.cmd. That is always been the rule.

NTLite worked around this limitation, by providing an optional OEM SetupComplete checkbox. All it did was insert an Unattended command to call the SetupComplete.cmd in a different install phase. Same functionality, but different trigger. Technically OEM SetupComplete ran ahead of schedule, compared to the normal Windows install (right after OOBE Setup).

Someone suggested another fix, which was an undocumented reg key to trigger tasks to run before or after OOBE. Since it's roughly at the same spot that normal Windows runs SetupComplete, this trigger replaced both solutions.

Nothing has functionally changed in running Post-Setup (Machine), other than the trigger. When it runs has shifted around. The old location for running it was between OOBE and new user setup. For W10 & 11, that's normally hidden behind the Windows Welcome "splash screen".

"You are getting sleepy.
Windows is doing something.
Please wait.
Watch this slow animation."

Now the unintended side effect is Post-Setup is more like W7, where you could see the install actions without being blocked.

I suppose if you're not installing on an OEM PC, deleting the new trigger will revert Windows' behavior to running SetupComplete in the original location. Which is behind the splash screen.
Code: 
[-HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\PostOobe]
 
garlin said:
The only recent change to Post-Setup was to allow OEM PC's to work the same as non-OEM PC's.

MS has very strict guidelines for OEM's (PC manufacturers and resellers); in exchange for volume licenses, they must follow specific rules on how to deploy non-Windows "crapware" in their customized images. When Windows detects the presence of any OEM product key in the BIOS, it skips running SetupComplete.cmd. That is always been the rule.

NTLite worked around this limitation, by providing an optional OEM SetupComplete checkbox. All it did was insert an Unattended command to call the SetupComplete.cmd in a different install phase. Same functionality, but different trigger. Technically OEM SetupComplete ran ahead of schedule, compared to the normal Windows install (right after OOBE Setup).

Someone suggested another fix, which was an undocumented reg key to trigger tasks to run before or after OOBE. Since it's roughly at the same spot that normal Windows runs SetupComplete, this trigger replaced both solutions.

Nothing has functionally changed in running Post-Setup (Machine), other than the trigger. When it runs has shifted around. The old location for running it was between OOBE and new user setup. For W10 & 11, that's normally hidden behind the Windows Welcome "splash screen".

"You are getting sleepy.
Windows is doing something.
Please wait.
Watch this slow animation."

Now the unintended side effect is Post-Setup is more like W7, where you could see the install actions without being blocked.

I suppose if you're not installing on an OEM PC, deleting the new trigger will revert Windows' behavior to running SetupComplete in the original location. Which is behind the splash screen.
Code: 
[-HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\PostOobe]
Click to expand...
I suppose i should have added this reg tweak in Integrate -> Registry? If so, doesn't work for me.

And what do you mean by the "splash screen"? Blue, breathing screen with some MS-messages? I don't remember when i had seen it last time, it's been ages. I always have my Post-Setup script executed in the other "splash screen": black, with the windows logo and a white spinner. Perhaps of my unattended <OOBE> config?
Code: 
            <OOBE>
                <HideEULAPage>true</HideEULAPage>
                <HideLocalAccountScreen>true</HideLocalAccountScreen>
                <HideOnlineAccountScreens>true</HideOnlineAccountScreens>
                <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
                <ProtectYourPC>3</ProtectYourPC>
                <SkipMachineOOBE>true</SkipMachineOOBE>
                <SkipUserOOBE>true</SkipUserOOBE>
            </OOBE>

Anyway, reverting back to 2023.6.9292 causes CMD issue to disappear, but i would appreciate to have a working solution or a workaround for the newest version of NTLite.
 

Attachments

  • sysprep.reg
    532 bytes
This should be tested on an unmodified install, using an official ISO or MCT image from Microsoft, to rule out large variables. The reason I mention this, is because the command prompt appearing on Windows 10 is actually a common issue that's been discussed for years. I've seen it myself on default installs of W10 Home 21H2, so there's a good chance Microsoft patched out the CMD bug, but then introduced it in a later build again.

Here's some examples of the discussions on the topic (link1, link2). I dug into this a bit when I first came across it, but I wasn't able to determine the source of the problem. Most people blame Microsoft Office products, but that wasn't the culprit for me. I didn't spend a ton of time on this and ultimately I just put it aside to test later on a newer Windows build.

It's still possible this specific thread is an NTLite bug of course, especially since it seems like a lot of threads are recently appearing regarding command prompts and post-setup issues, so something odd is going on right now. The question is who's responsible.
 
Last edited:
OK. I guess it doesn't work, because NTLite is applying the reg delete BEFORE it appends it's own postoobe key.

You can revert to 2023.11.9477, which is the last version before the SetupComplete switch.
 
This command will hide SetupComplete's CMD window. Insert it as the first line.
Code: 
powershell -nop Add-Type -MemberDefinition '[DllImport(""""User32.dll"""")]public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);' -Namespace Win32 -Name Functions; [Win32.Functions]::ShowWindow(((Get-Process -Id (gwmi Win32_Process -Filter "ProcessId=$PID").ParentProcessId)).MainWindowHandle,0)
 
garlin said:
This command will hide SetupComplete's CMD window. Insert it as the first line.
Code: 
powershell -nop Add-Type -MemberDefinition '[DllImport(""""User32.dll"""")]public static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);' -Namespace Win32 -Name Functions; [Win32.Functions]::ShowWindow(((Get-Process -Id (gwmi Win32_Process -Filter "ProcessId=$PID").ParentProcessId)).MainWindowHandle,0)
Click to expand...
This seems to hide the window after it's been shown. Too dirty IMO.

Instead, i settled for another workaround in order to revert changes introduced after NTLite 2023.11.9477. I have added this to my autounattend.xml:
Code: 
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Order>1</Order>
                    <Path>reg delete "HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\PostOobe" /f /va</Path>
                    <WillReboot>Never</WillReboot>
                </RunSynchronousCommand>
            </RunSynchronous>
        </component>
    </settings>
</unattend>

So far, so good. Thanks for pointing me in the right direction.
 
That works. My workaround is for users who can't write unattended files.

SetupComplete will never run by default if you're installing on a PC with an OEM license (Dell, HP, Lenovo, etc.). Deleting the PostOobe key would revert your image back to this expected behavior. Just keep that in mind.
 
Just a though.
MS recently (2-3 months ago) came up with more strict rules to force people into their MS Account (S***) Universe - especially those who be online when install.
So to my knowledge - the CMD prompt during install is looking to establish and download MS code to convience the ordinary user to make a MS Account which is removed with NTL ;)
 
The MSA requirement has no relevance to this discussion. Everything would still happen this way if you were installing W10.
I've covered what's going in detail. If you don't believe my explanation, then wait for abbodi to correct me.
 
Nestor said:
This seems to hide the window after it's been shown. Too dirty IMO.

Instead, i settled for another workaround in order to revert changes introduced after NTLite 2023.11.9477. I have added this to my autounattend.xml:
Code: 
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
            <RunSynchronous>
                <RunSynchronousCommand wcm:action="add">
                    <Order>1</Order>
                    <Path>reg delete "HKEY_LOCAL_MACHINE\SYSTEM\Setup\FirstBoot\PostOobe" /f /va</Path>
                    <WillReboot>Never</WillReboot>
                </RunSynchronousCommand>
            </RunSynchronous>
        </component>
    </settings>
</unattend>

So far, so good. Thanks for pointing me in the right direction.
Click to expand...
Hello, I have the same problem, it started after I updated NTLite, I just don't remember which version it was.

Is this code placed at the end or beginning of the file?
 
This code can be placed anywhere in the beginning or end of autounattend.xml (between the "unattend" tags). The order of the XML blocks doesn't matter as long as there isn't another settings pass="specialize" block.

Just remember, this doesn't work if your PC has a Windows product key in BIOS. The reg key you're deleting is what is needed to run the Post-Setup script on those PC's.
 
You must log in or register to reply here.
Back
Top