locked
WinPE5 x86 / W7 x64 BSOD on Lenovo devices RRS feed

  • Question

  • we just encountered a very strange bug in SCCM 2012 R2 OSD / ADK. After the migration of our SCCM 2012 infrastructure to 2012 R2 the OSD stopped to work on Lenovo devices (x230, S20, S30, ...). Everytime after applying the image and installing the device drivers the windows 7 minisetup stopped with a bluescreen (0x000000F4). We didn't change drivers or the windows 7 image. All that was different was an updated WinPE to version 5 (incl. ADK 8.1).

    We use one single task sequence to deploy x64 and x86 W7-installation. So we have a x86 boot-image in use. After extensive testing over the last few days we can confirm that the BSOD only happens with a x86 boot-image. It doesn't happen with a x64 boot-image. It also didn't help to change/update drivers. It look like DISM is doing something vey strange on those lenovo devices. We also have HP devices but they don't seem to have this problem at all.

    Can someone else confirm this? Somehow i can't find any other reports about this and i thought our configuration would be prety common.

    Wednesday, February 19, 2014 5:18 PM

Answers

  • yes, just recaptured the image. BUT with a new boot image (WinPE 5). I guess the capture with the newer DISM/ADK fixed the problem.
    • Proposed as answer by KravcA Tuesday, June 3, 2014 10:37 AM
    • Marked as answer by Juke Chou Wednesday, June 4, 2014 5:54 AM
    Friday, May 30, 2014 1:03 PM

All replies

  • Anything interesting in smsts.log when you use x86 boot image?

    Can you confirm that this boot image is the same version as x64 one?

    Wednesday, February 19, 2014 5:29 PM
  • no, there's no error in smsts.log. And when comparig the smsts.log from the x64 and x86 boot-image they look to do the exactly same thing. can't find what's wrong here and why it works with HP devices but doesn't with Lenovo.

    Thursday, February 20, 2014 7:35 AM
  • Sounds like this could be a UEFI issue to me and how you have BIOS configured.  Also, if it is Windows Setup that is blue screening you won't see any error in the SMSTS.log - if you boot a failed machine into WinPE again and take a look at the windows setup logs (setupact.log and setuperr.log) you may discover where the setup is getting to - could be a driver issue.

    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 9:57 AM
  • 0x000000F4. This indicates that a process or thread crucial to system operation has unexpectedly exited or been terminated. You could find out the process image name by analyzing the dump file.

    Also, we need to check setupact.log and setuperr.log


    Juke Chou

    TechNet Community Support


    • Edited by Juke Chou Thursday, February 20, 2014 10:40 AM
    Thursday, February 20, 2014 10:35 AM
  • UEFI is completely disabled. (we had to do this already on SCCM 2012 where it worked until the R2 upgrade)

    There is nothing written to SetupAct.log and SetupErr.log. The only thing which gets updated is the setup.etl file but it's corrupt. I can't open it and sadly it's a binary file. It seems like windows crashes even before initializing the drivers. I'm pretty sure it has something to do with the changes which happen in WinPE while applying the system settings with dism. (clean winpe without drivers leads to the same problem as well)

    Thursday, February 20, 2014 10:45 AM
  • Could you confirm exactly when the BSOD occurs - is it when you see "Setup is installing drivers... X%".

    I'm amazed how you don't have anything recorded in the setupact.log or setuperr.log.  IIRC these logs exist in more than one place - windows\panther, windows\panther\unattendGC?

    Temporarily try using the install.wim from the Windows 7 DVD, in case it is something in your image.

    I'm not a huge fan of a single Task Sequence that attempts to deal with x86 and x64 deployments - too much duplication of steps to ensure the right step runs for the right architecture.


    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 12:23 PM
  • i'm going through the memory.dmp with windbg now. that's what i got so far.

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    CRITICAL_OBJECT_TERMINATION (f4)
    A process or thread crucial to system operation has unexpectedly exited or been
    terminated.
    Several processes and threads are necessary for the operation of the
    system; when they are terminated (for any reason), the system can no
    longer function.
    Arguments:
    Arg1: 0000000000000003, Process
    Arg2: fffffa800a290060, Terminating object
    Arg3: fffffa800a290340, Process image file name
    Arg4: fffff800029d0d60, Explanatory message (ascii)

    Debugging Details:
    ------------------


    PROCESS_OBJECT: fffffa800a290060

    IMAGE_NAME:  wininit.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  0

    MODULE_NAME: wininit

    FAULTING_MODULE: 0000000000000000

    PROCESS_NAME:  wininit.exe

    EXCEPTION_CODE: (Win32) 0x36b1 (14001) - The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

    BUGCHECK_STR:  0xF4_36b1

    DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

    CURRENT_IRQL:  0

    ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) amd64fre

    STACK_TEXT: 
    fffff880`04c569c8 fffff800`02a5a172 : 00000000`000000f4 00000000`00000003 fffffa80`0a290060 fffffa80`0a290340 : nt!KeBugCheckEx
    fffff880`04c569d0 fffff800`02a06d5b : 00000000`00000001 fffffa80`0a2906e0 fffffa80`0a290060 00000000`00396240 : nt!PspCatchCriticalBreak+0x92
    fffff880`04c56a10 fffff800`02984ac4 : 00000000`00000001 00000000`00000001 fffffa80`0a290060 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x16eb6
    fffff880`04c56a60 fffff800`026c6913 : fffffa80`0a2906e0 fffff880`000036b1 fffffa80`0a2906e0 fffffa80`0a29bb30 : nt!NtTerminateProcess+0xf4
    fffff880`04c56ae0 00000000`776215da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
    00000000`0016f698 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x776215da


    STACK_COMMAND:  kb

    FOLLOWUP_NAME:  MachineOwner

    IMAGE_VERSION: 

    FAILURE_BUCKET_ID:  X64_0xF4_36b1_IMAGE_wininit.exe

    BUCKET_ID:  X64_0xF4_36b1_IMAGE_wininit.exe

    ANALYSIS_SOURCE:  KM

    FAILURE_ID_HASH_STRING:  km:x64_0xf4_36b1_image_wininit.exe

    FAILURE_ID_HASH:  {d980452f-09ba-ff6f-43b9-427fbbba0095}

    Followup: MachineOwner
    ---------

    Thursday, February 20, 2014 12:25 PM
  • BSOD occurs while/after the "starting windows" screen (boot animation). It never shows the "setup is installing drivers screen". The "starting windows"-screen is all i can see before the BSOD.

    setupact.log and setuperr.log checked in c:\windows, c:\windows\panther and c:\windows\panther\unattendGC. te setuperr.log is always 0 KB and the setupact.log has only entries from the time the image was captured.

    i know it's not the perfect solution but it was the best user experience for our IT support staff if we can dynamically set the correct architecture while installing. And it actually worked perfect before the R2 upgrade.

    I'm doing the test with a bare install.wim from the DVD now. But there really must be a change how dism works in R2.

    Thursday, February 20, 2014 12:55 PM
  • After your R2 upgrade, is your task sequence using the standard Boot Images (which will have been upgraded) or are referencing your own custom Boot Image (which will not be upgraded.)

    Are you injecting any mass storage drivers in your driver packages for these models?

    Do you have any mass storage or network drivers in whatever Boot image you are using? If so, are these absolutely compatible with Windows 8.1 (I've seen vendor drivers report to SCCM that they 'support' Windows 8.1, but in fact they do not.  The Intel 82579-LM driver for instance, has a specific NDIS64 driver folder)


    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 1:16 PM
  • currently i'm debugging with a completely new winpe5 boot-image. NO drivers added at all. But it has the same problem like our migrated boot-image.
    Thursday, February 20, 2014 1:19 PM
  • ok. one step closer. It WORKS with a direct install.wim from the W7 SP1 x64 DVD. But why did our captured image work with 2012 and doesn't anymore with R2?!

    I will try to capture a new one now.

    Thursday, February 20, 2014 1:31 PM
  • What system did you build and capture your Reference Image with?  You probably already know that it's best to use basic hardware (like a Dell 780 desktop or similar - that requires ZERO drivers to run) or more ideally a virtual machine with a legacy NIC and IDE controller setup. I'm wondering if your captured image has a critical boot driver conflict with something in WinPE5.


    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 1:43 PM
  • the image was captured on a hyper-v vm to exactly reduce the prenstalled drivers. and the same image works when we use WinPE5 x64 instead of x86.
    Thursday, February 20, 2014 1:47 PM
  • Is there any chance you had saved some Lenovo drivers in your previous image capture process?
    Thursday, February 20, 2014 1:47 PM
  • the image was captured on a hyper-v vm to exactly reduce the prenstalled drivers. and the same image works when we use WinPE5 x64 instead of x86.

    Gen1 or Gen2 Hyper-V VM?  Gen-2 is 64bit only AFAIK.  With or without Hyper-V integration installed?

    My Personal Blog: http://madluka.wordpress.com


    • Edited by MadLuka Thursday, February 20, 2014 1:59 PM
    Thursday, February 20, 2014 1:58 PM
  • Gen1. Gen2 doesn't support W7
    Thursday, February 20, 2014 1:59 PM
  • Ah, of course. I'm struggling to think what could have gone wrong - as I've used both Hyper-V and VMWare to capture images and deploy them to pretty much most models and makes of equipment, including Lenovo X and T series. My general approach has always been to create a new reference image (with the new SCCM client version installed) and migrate existing Task Sequences into a new MDT 2013 Task Sequence as I know that some MDT steps (such as Execute Runbook) in an MDT 2012 Task Sequence do not work with the MDT 2013 Toolkit. This usually occupies the most time during any R2 upgrade engagements I've done.

    My Personal Blog: http://madluka.wordpress.com

    Thursday, February 20, 2014 2:07 PM
  • recaptured image seems to work. very strange behaviour that this only affected lenovo with a x86 boot image..
    Tuesday, February 25, 2014 12:51 PM
  • Funny i have issue similar in Vmware.

    I have deployed (successfully) from WIM to a VMWARE client installed all software and windows updates and captured.

    When deploying this captured image the "setup windows and config mgr" (same configuration as used in the prior WIm deployment) the machine reboots, and 83% into "setting up devices" i get  BSOD.

    if i remove the setup of SCCM 2012 the image builds into windows perfectly. I wonder is a update is causing the issue as with VMware we are using a "minimal" of drivers, and the prior deployment was ok (No additional drivers added only software).

    I know your issue is with Lenovo but maybe its also windows updates related (depending what is in your image)


    • Edited by AlexjHill Thursday, February 27, 2014 9:40 AM
    Thursday, February 27, 2014 9:38 AM
  • I have exactly the same problem symptoms... 

    Can you provide more information on how you managed to fix it?

    You are mentioning recapturing image.. Did you just recaptured the same way as usual or you changed from HyperV to VMware? 

    Wednesday, May 28, 2014 6:33 PM
  • yes, just recaptured the image. BUT with a new boot image (WinPE 5). I guess the capture with the newer DISM/ADK fixed the problem.
    • Proposed as answer by KravcA Tuesday, June 3, 2014 10:37 AM
    • Marked as answer by Juke Chou Wednesday, June 4, 2014 5:54 AM
    Friday, May 30, 2014 1:03 PM
  • Yes, that was it!

    Recaptured with updated ADK8.1 and now no more BSODs. Thanks.

    Tuesday, June 3, 2014 10:38 AM
  • A very specific problem solved.

     

    1. X64 Images built on MDT 2013 (build booting from LiteTouchPE_x64.iso)
    2. And deployed on SCCM 2012 R2 (Booting from WinPE x86) will fail on some PC’s.

     

    Specifically we have the problem on E744/E754 with i7 CPU / 8GB RAM.

    Exact same model but with i5 /4GB has no issues…

     

    All we needed was to use the WinPE x64.

    • Proposed as answer by EarnestK Tuesday, December 9, 2014 7:44 PM
    Thursday, November 13, 2014 10:36 AM
  • A very specific problem solved.

    1. X64 Images built on MDT 2013 (build booting from LiteTouchPE_x64.iso)
    2. And deployed on SCCM 2012 R2 (Booting from WinPE x86) will fail on some PC’s.

    Specifically we have the problem on E744/E754 with i7 CPU / 8GB RAM.

    Exact same model but with i5 /4GB has no issues…

    All we needed was to use the WinPE x64.

    Thank you for posting this! This resolved my issue with Dell Precision T5610 desktops that I've been working on.
    Tuesday, December 9, 2014 7:44 PM
  • Though this Post is old. This saved me from the frustration i had on what was wrong. Its not Just BSOD's with STOP F4 but also i saw that the drivers such as network and audio service were not functional on HP Devices and the network icon used to end up with Red Cross but the device was still able to reach out to the internet. Everything worked except for Lync as it was looking for an Active Wi-fi Connection. 

    For the rest please ensure that the Dism you are using to capture Windows 7 always matches with WINPE. An higher DISM version can also be used to capture Windows 7 and restore it on a Lower Dism version. Doing this the other way round might have complications. This is applicable to WINPE 32 bit images. i am not sure of WINPE 64 bit as we dont use WINPE 64 bit in our environment. 

    So I cant say enough thanks to you.

    Sunday, January 24, 2016 7:45 PM
  • See: http://blogs.technet.com/b/dip/archive/2015/01/21/win2008r2-win7-stop-0xf4-during-task-sequence-os-deployment.aspx

    We still have 32-bit OSs to support, so we went with option 2b as described in the article, setting the boot image to not compress the registry when it loads.

    • Proposed as answer by KravcA Wednesday, February 24, 2016 6:53 PM
    Wednesday, February 24, 2016 6:45 PM