none
Windows 7 Imag hangs at splash screen RRS feed

  • Question

  • I'm having an issue getting an image to complete successfully on a HP 635 laptop.

    The image I'm using was created on a VM and it's used on other laptop/desktops successfully.

    The process works find until the laptop reboots and the windows splash screen comes up. And at that point it does not proceed any further.  Shift F10 does not switch me to the command prompt so I can't check log files or make any registry changes that might correct the problem.  If I power off the unit and go into command prompt safe mode I see that it load drivers until it gets to afcmx64.sys then stops.  I have tried renaming this file suspecting that there maybe an issue with it but the boot up doesn't work as it complains that the file is missing.   I can however, install windows 7 from a CD without issue.

    I have checked this form and searched the internet but have not found a match for my issue. If anyone has gone through this and has a fix for it I would appreciate you help.

    thanks


    Kris Da San Martino

    Wednesday, June 4, 2014 2:38 PM

Answers

  • Hi Kris,

    I would suggest you look at the bdd.log file and see if you can pinpoint the issue.  It sounds like it is driver related.  You should be able to boot back into the boot image (winpe) and navigate to the C drive to pull the bdd.log file (should be located under C:\minint\smsosd\osdlogs).  

    Also, the period of time while it is in WinPE, it copies all the drivers to the C drive before it starts applying the image.  You can pull the bdd.log file from the C drive when it starts applying the image to see what drivers it finds and which hardware it doesn't find drivers for.

    Without knowing how you have your environment setup regarding the drivers it is going to be hard to pinpoint.  If you are using the "Bucket" method versus the "Control Freak" method would help a little.

    Wednesday, June 4, 2014 3:04 PM

All replies

  • Hi Kris,

    I would suggest you look at the bdd.log file and see if you can pinpoint the issue.  It sounds like it is driver related.  You should be able to boot back into the boot image (winpe) and navigate to the C drive to pull the bdd.log file (should be located under C:\minint\smsosd\osdlogs).  

    Also, the period of time while it is in WinPE, it copies all the drivers to the C drive before it starts applying the image.  You can pull the bdd.log file from the C drive when it starts applying the image to see what drivers it finds and which hardware it doesn't find drivers for.

    Without knowing how you have your environment setup regarding the drivers it is going to be hard to pinpoint.  If you are using the "Bucket" method versus the "Control Freak" method would help a little.

    Wednesday, June 4, 2014 3:04 PM
  • thanks for you input on this.

       I will try again and pull the logs. As far as how I classify my setup I guess it would be "Control Freak".

    I have drivers loaded for each model underneath folders for that model name.

    I'll get back to you with what I find.


    Kris Da San Martino

    Thursday, June 5, 2014 4:42 PM
  • I managed to get the BDD.log and scanned through it and could find anything that would indicate what the issue might be.   What should I be looking for or can I post the file for you (or someone) to look at?

    thanks


    Kris Da San Martino

    Thursday, June 5, 2014 10:18 PM
  • there is the log file http://1drv.ms/Sz8yhD


    Kris Da San Martino

    Tuesday, June 10, 2014 7:21 PM
  • Hi Kris,

    I assume you are using the latest version of MDT 2013 and Windows ADK 8.1 update1.

    WinPE 4.0 and 5.0 can cause the Windows Splash screen to hang, due to outdated hardware support. If available, perform a BIOS update and try to run the deployment again.

    Another viable option, could be driver selection and targeting. Please make sure that your laptop only receives the drivers that are intended for this particular model, and make sure no VMware or Hyper-V drivers are targeted to the machine. (this can also be seen in the bdd.log).

    Deployments are especially susceptible to storage drivers, the numerous times I've seen the "iaStore.sys" error on the MDT forums is out of proportion, all due to bad driver management.

    If you need so guidelines on driver management, please check this site: MDT 2013 Lite Touch Driver Management

    Cheers!


    If this post is helpful please click "Mark for answer", thanks! Kind regards

    Thursday, June 12, 2014 11:35 AM
  • My personal trick when looking for drivers within the bdd.log file is to grep for the string "xcopy". "Xcopy" is used to copy the physical driver packages to the local machine. I can see that you are copying a *lot* of drivers here.

    Yes, the problem is most likely a driver issue, best course of action is to remove as many drivers as you can from your deployment (not the WinPE Image). If the MDT installation passes then you have a driver issue, and it may come down to manually adding/removing *each* driver package until you find the culprit.


    Keith Garner - Principal Consultant [owner] - http://DeploymentLive.com

    Thursday, June 12, 2014 8:57 PM
    Moderator
  • Thanks to both of your comments.

    I'll look into what you have suggested.  Just as a note I have my server setup so that one image can be used for any desktop or laptop regardless of the model (we us just HP here) so that would explain why so many drivers are being copied. 

    I'll start with a BIOS update and work my way to narrowing down the drivers list and post my results.


    Kris Da San Martino

    Friday, June 13, 2014 2:29 PM
  • just found out that my MDT server is not 2013 so the testing I did the last few days was not correct.

    The good news is that I do have a 2013 MDT server already to go so testing will start on that box


    Kris Da San Martino

    Tuesday, June 17, 2014 10:55 PM
  • I have run one test with my MDT 2013 server and still did not get it to work.

    I setup the task seq. so that it would only load drivers for that model of computer. (And in this test case there were only the two nic drivers ).

    I'm going to try and install just a windows 7 OS to see how if it works.


    Kris Da San Martino

    Thursday, June 19, 2014 3:33 PM
  • As Rens suggested use the "Total Control" method shown on Johan's blog. I'd suggest making use of the ModelAlias userexit script in order to account for models that report under different names but in fact use the same driver sets. Make sure you follow it exactly, setting your drivergroup variable and setting the selection profile. This method works very well, speeds up the process and is cleaner. Also make sure you have the right PE 5 drivers and don't forget to update the deployment share so that the boot image will work correctly.

    If you're not already doing this use the HP SoftPaq Download Manager to get drivers.


    If this post is helpful please vote it as Helpful or click Mark for answer.

    Thursday, June 19, 2014 9:24 PM