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

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.

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.
I didn't understand, because the code itself already comes with the "unattend" tags and the autounattend.xml file already comes with the same tags too.

Another question is how to proceed if my machine already has a key saved in the BIOS, as all computers from 2013 to now almost all come with the key in the BIOS.
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.


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 t
 
You didn't pay close attention to my previous notes (post #9).

1. Windows ISO as directly provided by MS downloads, has the ability to run a Post-Script script if it's specifically named "\Windows\Setup\Files\SetupComplete.cmd". This logic is skipped if you have a BIOS license key (ie. Dell, HP, Lenovo, ASUS). OEM's are allowed to customize their "factory" images to some degree, but aren't permitted to use SetupComplete.cmd.

2. The old version of NTLite offered an optional workaround for these PC's, which would substitute an unattended "specialize pass" command, to execute SetupComplete.cmd. The same script is run, but it's launched by the XML configs.

3. The current version of NTLite removed the optional checkbox and moved to a single solution for all PC's. New users didn't understand why they needed to use the OEM SetupComplete option in the first place. This new feature embedded a registry task to run the same script.

4. Because options 1, 2 & 3 all work in different ways, the user doesn't see the same displays:
- Option 1 runs after OOBE, but Windows hides all actions (by design) behind a splash screen.​
- Option 2 runs before OOBE​
- Option 3 runs after OOBE, but there's no screen hiding the command. Because the script is running @ECHO OFF, you get a black (no output) CMD window which stays open, until SetupComplete.cmd is done.​
5. For users who don't have a BIOS license, they can delete the reg key and the install process works like Option 1 again. OEM users can't do that, and must revert to NTLite's old method for Option 2.

Option 3 is the best answer for all PC's, but there's an identified NTLite bug where the attempt to minimize (or hide) the parent CMD shell doesn't work really well. For you I would recommend this temporary solution:

Add this command as the FIRST line in "Before logon":

CommandParameters
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 (gcim Win32_Process -Filter "ProcessId=$PID").ParentProcessId)).MainWindowHandle,0)

This PS command completely hides (not minimizes) the CMD window.
 
You didn't pay close attention to my previous notes (post #9).

1. Windows ISO as directly provided by MS downloads, has the ability to run a Post-Script script if it's specifically named "\Windows\Setup\Files\SetupComplete.cmd". This logic is skipped if you have a BIOS license key (ie. Dell, HP, Lenovo, ASUS). OEM's are allowed to customize their "factory" images to some degree, but aren't permitted to use SetupComplete.cmd.

2. The old version of NTLite offered an optional workaround for these PC's, which would substitute an unattended "specialize pass" command, to execute SetupComplete.cmd. The same script is run, but it's launched by the XML configs.

3. The current version of NTLite removed the optional checkbox and moved to a single solution for all PC's. New users didn't understand why they needed to use the OEM SetupComplete option in the first place. This new feature embedded a registry task to run the same script.

4. Because options 1, 2 & 3 all work in different ways, the user doesn't see the same displays:
- Option 1 runs after OOBE, but Windows hides all actions (by design) behind a splash screen.​
- Option 2 runs before OOBE​
- Option 3 runs after OOBE, but there's no screen hiding the command. Because the script is running @ECHO OFF, you get a black (no output) CMD window which stays open, until SetupComplete.cmd is done.​
5. For users who don't have a BIOS license, they can delete the reg key and the install process works like Option 1 again. OEM users can't do that, and must revert to NTLite's old method for Option 2.

Option 3 is the best answer for all PC's, but there's an identified NTLite bug where the attempt to minimize (or hide) the parent CMD shell doesn't work really well. For you I would recommend this temporary solution:

Add this command as the FIRST line in "Before logon":

CommandParameters
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 (gcim Win32_Process -Filter "ProcessId=$PID").ParentProcessId)).MainWindowHandle,0)

This PS command completely hides (not minimizes) the CMD window.
 
Is not working.

Does not leave the first black sc

There are iso's that I create until I can install, but after the first automatic restart of the installation it hangs on a black screen.reen
 
Last edited:
Is this a separate problem with a Post-Setup command not finishing? Please attach your preset, after removing any user passwords or license key.
 
Hello, garlin and nuhi!

I hope I understand, as English is not my native language and I use Google Translate to communicate with you.

I'm new to NTLite and I'm just a regular user.

I made a new ISO in version 2024.3.9833, but without success.

Went through the initial installation screen, but got stuck after rebooting on the black screen with the white circles spinning, before the OOBE.

Attached is the preset file. There were 4 ISO's created with practically the same configuration:

In ISO 1 I selected the OEM checkbox without the command mentioned by garlin;

In ISO 2 I selected the OEM checkbox with the command mentioned by garlin;

In ISO 3 I deselected the OEM checkbox with the command mentioned by garlin;

In ISO 4 I deselected the OEM checkbox without the command mentioned by garlin;
 

Attachments

  • Salvo automaticamente a81e6098.xml
    21.9 KB
Hi, again!

I noticed here, doing some more testing, that the command mentioned by garlin is not being integrated and processed during ISO processing, as you can see in the attached image, the little ball does not turn green.

1711765310560.png
 
Just a thought.
Seen it so many times - ntl user load a preset lock every setting and update the image same time.
How can the locked removals know there been updated.
A good advice is load your image for updates only and save it.

After, load it again and after removals load it third time an go to Updates tab and do a dism Compatible and save the image from here - it'll allow WU to do the job without concern unless you've removed some critical components.
 
Just a thought.
Seen it so many times - ntl user load a preset lock every setting and update the image same time.
How can the locked removals know there been updated.
A good advice is load your image for updates only and save it.

After, load it again and after removals load it third time an go to Updates tab and do a dism Compatible and save the image from here - it'll allow WU to do the job without concern unless you've removed some critical components.
I don't understand your answer.

After the March 2024 re-design, the Post-Setup method changed, and apparently changed again. Depending on the last NTLite version you used, some of these problems may have been fixed, or the "new" approach isn't the same thing.

I haven't commented on "new" Post-Setup because I'm still trying to figure the true impact of these changes.
2024.3.9833 - March 26, 2024

Fix

Post-setup: ‘Before logon’ tasks again do not need OEM SetupComplete option, leaving it as an option

2024.3.9831 - March 25, 2024

Upgrade

Unattended: ‘OEM SetupComplete’ returned as an option for those that need it with OEM machines

2023.11.9515 -November 29, 2023

Upgrade

Unattended: ‘OEM SetupComplete’ option automated on Win10+ with OEM keys and removed the option
 
Apenas um pensamento.
Já vi isso tantas vezes - o usuário ntl carrega um bloqueio predefinido em cada configuração e atualiza a imagem ao mesmo tempo.
Como as remoções bloqueadas podem saber que foram atualizadas.
Um bom conselho é carregar sua imagem apenas para atualizações e salvá-la.

Depois, carregue-o novamente e após as remoções, carregue-o pela terceira vez, vá para a guia Atualizações e faça um dism Compatível e salve a imagem aqui - isso permitirá que o WU faça o trabalho sem preocupação, a menos que você tenha removido alguns componentes críticos.
Sorry, but I didn't understand your answer either
 
Eu não entendo sua resposta.

Após a reformulação de março de 2024, o método pós-configuração mudou e, aparentemente, mudou novamente. Dependendo da última versão do NTLite que você usou, alguns desses problemas podem ter sido corrigidos ou a "nova" abordagem não é a mesma coisa.

Não comentei sobre a "nova" pós-configuração porque ainda estou tentando descobrir o verdadeiro impacto dessas mudanças.
Hi friend, I'm glad you're checking the bug, did you review my last preset I attached?

VI also notice that the command that was passed is not being integrated into the image process
 
The images were taken in the 3 post-configuration options: 'Before login'

And still on the black screen with the white balls spinning prereenlls ningningning
 
Last edited:
Find out the reason for the black screen (I think).

When you change services in NTLite, and these services are blocked in the installed Windows, the black screen bug occurs.

So I listed the services that I didn't change in NTLite and that are blocked in Windows Installed and then went to OOBE without any problems. Below is the list of services.

  • RPC Endpoint Mapper
  • RPC (Remote Procedure Call)
  • Bluetooth User Support Service
  • Shared PC Account Manager

So whoever is having this problem and wants to disable or change to manual any service that is blocked in Installed Windows, don't touch it, as it will give you a black screen.
 
Back
Top