VMware VM with more than 1 vCPU BSoD when loading WinPE using WIMBOOT

[pxe_curious]

Ran into an issue booting WinPE using WIMBOOT:

- Happens on VMware 5.5 and 6.0 with latest updates.
- Happens whether I use undionly.kpxe, ipxe.pxe or ipxe.kpxe.
- Only happens with VMs that have more than 1 vCPU. 1 vCPU = no problem.
- Only happens when the VM is using a legacy BIOS, no problem if using EFI.
- The WinPE I am using does have drivers injected into it, but I also tested with an unaltered WINPE.WIM with same effect.
- Also booted the WinPE via ISO and it did not BSoD, hence not a driver issue with the WinPE.
- Using latest WIMBOOT 2.5.2.
- No problem with physical hardware with 2 sockets. Problem seems to be limited to VMware VMs.
- Tried VM Hardware types 9, 10 and 11 and also with different versions of Guest OS types.

Code snippet of iPXE script that loads the content:

Code:

iseq ${arch} 64 && set winpe winpe_x64.wim || set winpe winpe_x86.wim
imgselect ${url}/win/wimboot gui
imgfetch --name bcd                ${url}/win/bcd                       bcd
imgfetch --name boot.sdi           ${url}/win/boot.sdi                  boot.sdi
imgfetch --name segmono_boot.ttf   ${url}/win/fonts/segmono_boot.ttf    segmono_boot.ttf
imgfetch --name segoe_slboot.ttf   ${url}/win/fonts/segoe_slboot.ttf    segoe_slboot.ttf
imgfetch --name segoen_slboot.ttf  ${url}/win/fonts/segoen_slboot.ttf   segoen_slboot.ttf
imgfetch --name wgl4_boot.ttf      ${url}/win/fonts/wgl4_boot.ttf       wgl4_boot.ttf
imgfetch --name boot.wim           ${url}/windows/pxeboot/${winpe}      boot.wim
imgexec

I also tried without loading the fonts and not specifying the 'gui' option for WIMBOOT.

The BSoD I get with the 64-bit WinPE is PAGE_FAULT_IN_NONPAGED_AREA (STOP: 0x00000050).

The 32-bit WinPE's BSoD is IRQL_NOT_LESS_OR_EQUAL (STOP: 0x0000000A).

If I set the VM to 1 vCPU, it PXE boots fine, loads undionly.kpxe, loads and executes the script, loads all images and starts bootmgr which loads the image files and then starts the WinPE. Everything works as expected.

If I set the VM to 2 vCPU (or more), it PXE boots fine, loads undionly.kpxe, loads and executes the script, loads all images and starts bootmgr which loads the image files and then tries to start Windows at which point it briefly hangs and then shows the BSoD.

If I then change the vCPU count back to 1, it boots fine again. This is true for both the 32-bit and 64-bit WinPE.

Any ideas what can be done here?

Screenshots:
BSOD 64-bit: http://imgur.com/8sTrvvx
BSOD 32-bit: http://imgur.com/F373cGn
WIMBOOT: http://imgur.com/kNInEus

[d4rk3]

Try VM hardware type 8...

[pxe_curious]

(2016-07-01 16:12)d4rk3 Wrote:  Try VM hardware type 8...

I wouldn't have thought so, but hardware type 8 does work with more than one vCPU.

Any idea what the difference is and how to get the later hardware types working?

---

I did some more testing and hardware type 8 and 9 are working. I probably screwed up my earlier test of hardware type 9.

But a new VM with hardware type 8 boots fine into WinPE using WIMBOOT.
Also upgrading the VM from type 8 to type 9 works.
Also a new VM created as type 9 works.

Upgrading to type 10 or creating a new machine as type 10 both fail with the BSoD.
Same is true for type 11.

[pxe_curious]

After some more testing I believe I found a work-around by building a BCD that will restrict WinPE to one CPU.

This is the script I created to build my custom BCD:

Code:

@ECHO OFF
SETLOCAL
IF /I {%1} EQU {debug} SET BCDDEBUG=TRUE
IF EXIST wimboot_bcd DEL /F /Q wimboot_bcd

bcdedit -createstore wimboot_bcd
SET BCDEDIT=bcdedit -store wimboot_bcd

REM This BCD is specifically for use with Wimboot and WinPE. It will force WinPE to use only one CPU.

:RAMDISKOPTIONS
REM No description for ramdiskoptions!
%BCDEDIT% -create {ramdiskoptions}
%BCDEDIT% -set {ramdiskoptions} ramdisksdidevice boot
%BCDEDIT% -set {ramdiskoptions} ramdisksdipath \Boot\boot.sdi

:WINPE
for /f "tokens=3" %%i in ('%BCDEDIT% -create -d "WIMBOOT WinPE" -application osloader') do set GUID1=%%i
%BCDEDIT% -set %GUID1% systemroot \Windows
%BCDEDIT% -set %GUID1% detecthal Yes
%BCDEDIT% -set %GUID1% winpe Yes
%BCDEDIT% -set %GUID1% osdevice ramdisk=[boot]\Boot\boot.wim,{ramdiskoptions}
%BCDEDIT% -set %GUID1% device ramdisk=[boot]\Boot\boot.wim,{ramdiskoptions}
%BCDEDIT% -set %GUID1% onecpu on

:BOOTMGR
%BCDEDIT% -create {bootmgr} -d "Windows Boot Manager"
%BCDEDIT% -set {bootmgr} timeout 30
%BCDEDIT% -set {bootmgr} default %GUID1%
%BCDEDIT% -set {bootmgr} displayorder %GUID1%

IF /I {%BCDDEBUG%} EQU {TRUE} (
    ECHO.
    ECHO Debug options included
    %BCDEDIT% -create {dbgsettings}
    %BCDEDIT% -dbgsettings SERIAL DEBUGPORT:1 BAUDRATE:115200 -start AUTOENABLE

    %BCDEDIT% -bootdebug {bootmgr} on
    %BCDEDIT% -bootdebug %GUID1% on
    %BCDEDIT% -debug %GUID1% on
)

:VIEW_FINAL
%BCDEDIT% -enum all -v

ECHO.
ECHO Your new BCD file is called wimboot_bcd. Rename it to whatever you need.
ENDLOCAL

The important line is the one with 'set onecpu on'. This makes it so that WinPE only sees one CPU. For the purpose of WinPE (at least in my case) that is completely fine.

I have tested this on VMware hardware type 10 and 11 with more than one vCPU and the BSoD is no longer happening.

[mcb30]

(2016-07-05 17:07)pxe_curious Wrote:  

Code:

%BCDEDIT% -set %GUID1% onecpu on

Great debugging; thank you for writing up the workaround here!

Michael

[marcel]

I have had the same problem but my BSOD Error was "SYSTEM_THREAD_EXCEPTION_NOT_HANDLED". After Setting the CPU to only 1 vCPU it has working.

[john9871]

I am having SYSTEM THREAD EXCEPTION NOT HANDLED problem in my Pc.

[john9871]

actually i reached about this error last night and came across this article related to this error
so, the article says my boot volume got corrupted and it does what i've found at the end
here's the command what i use in cmd.
opened cmd by my windows usb stich, great thing which i've also learned by the way
Command 1# – Diskpart

Command 2# – List volume

Command 3# – Exit
Command 4# – D: (You’re Windows Drive Letter)

Command 5# – Bootrec /fixmbr

Command 6# – Bootrec /fixboot

Command 7# – Chkdsk /f (Try chkdsk /f /r If “Chkdsk /f” command Wont Works)

Command 8# – Y

After “chkdsk” command completes, just restart my computer and I my problem is solved.



http://www.deskdecode.com/how-to-fix-sys...x0000007e/

[jensgw]

Hi there,

giving this a bump.
With the latest wimboot (2019-08-09) this error is still present with virtual box (6).
When you boot the VM with 1 CPU winpe works.
With more CPUs there is the same error: PAGE_FAULT_IN_NONPAGED_AREA

Cheers Jens

p.s. trying to build wimboot on linux results in many error of the kind:
main.i386.s:79: Error: 8-byte relocation cannot be applied to 4-byte field

[NiKiZe]

Use a clean BCD for example this one: https://github.com/NiKiZe/wimboot-bcd
If this does not help, report this to wmvware and microsoft, since this seems to work with qemu and real hardware without issues

[jensgw]

Thx, will try.
However, the page fault is also with using qemu/kvm and more than 1 cpu core.