Dell Precision 5810 - Megasas2.sys error 359 BSOD during deployment on reboot using MDT 2013 U2 RRS feed

  • Question

  • Hello,

    We have a Dell T5810 Precision i am trying to deploy with MDT 2013 U2 using Total Control
    I am getting a BSOD Megasas2.sys error 359 on reboot, up until that point the drive is detected, formatted, drivers deployed and OS installed (Win7 SP1).  When i check the dynamic logs, no errors are appearing there. There is no NVME drive, its just a normal Samsung SM871 and the BIOS has been set to AHCI no RAID. we have the same SSD in many other Dell products and no problems with deployment.

    I have tried booting with just 32 bit drivers, just 64 bit drivers, removing the Megasas2.sys 64bit drivers from LSICorp that get thrown in the boot.wim on updating the DeploymentShare. I have also tried the latest WinPE 3.0, 5.0 and 10 Cab packs from the Dell website which has made no difference to the error being recieved.

    I can build the box manual and install drivers, but that doesn't fix the issue that is presented and defeats the purpose of having MDT in the first place.

    Can anyone offer any suggestions??

    Tuesday, November 8, 2016 10:21 PM

All replies

  • I'm having the same issue but with a Precision T7810. Imaging using MDT, no errors in my logs. Driver looks like it's being pulled down from my deployment server but once the image is applied, the machine won't boot into Windows to finish the task sequence. I've confirmed my BIOS settings for a SSD boot but still no success. Any suggestions or help would be greatly appreciated.
    Monday, December 12, 2016 7:17 PM
  • First of all: How to Debug missing Drivers in MDT Litetouch

    I would go through the bdd.log file and look for all instances of xcopy.exe, ZTIDrivers.wsf will copy drivers from your MDT share to the local machine using xcopy, and no other tool uses xcopy, so it's a good way to start looking at what drivers are actually getting copyied down.

    Additionally, please be aware that if you get a BSOD, there is a difference between error 359 and 0xc0000359

    the first is meaningless, the second is more interesting:

    C:\>err 359
    # NOT FOUND: 359

    C:\>err 0xc0000359 # for hex 0xc0000359 / decimal -1073740967 : STATUS_INVALID_IMAGE_WIN_32 ntstatus.h # The specified image file did not have the correct format, # it appears to be a 32-bit Windows image. # 1 matches found for "0xc0000359"

    This suggests that you are trying to inject either the x86 storage driver into your x64 image.

    (or perhaps you are trying to inject a x64 driver into a x86 image, in which case I would be disgusted at you, you shouldn't be using a Windows 7 x86 image on a high end machines, when you do this the angels weep).

    Intel drivers have been notorious in the past for being difficult to determine if they are x86 vs x64, so MDT has problems loading the right one.


    Keith Garner - Principal Consultant [owner] -

    Monday, December 12, 2016 10:17 PM
  • So I don't think it's a driver issue. Rather, it may be a sysprep issue. If I boot into safe mode once following the image deployment (after I receive the error), I see the same error during the safe boot process. I then reboot and the deployment finishes as it should. So I'm puzzled. What is it that is going on during the safe boot process that could be "correcting" the issue that is preventing the task sequence from completing as normal the first time it's executed?

    It's probably worth mentioning a little background: I've been using MDT for about 8 months now as an imaging solution and this is the first time I've had this issue. I have a reference image that is a VM that I regularly update, patch (bigfix), shutdown, clone, and then sysprep and capture that I use as my custom image. I then import that .wim file and update the "Install Operating System" step for my task sequence. This method has worked fine without issue for the last 8 image releases. The error suddenly started happening after the December updates were applied to the image.

    As always, any help you can provide is greatly appreciated.

    Wednesday, December 28, 2016 3:45 PM
  • Hi - were you ever able to trace down what this issue was?

    Running into this exact same thing now, Precision Tower 5810, images fine on a Precision 7710 laptop but the tower has issues. Standard Samsung drive, tried in RAID and AHCI mode and both behave the same, using Dell driver CAB from their website, getting the exact same symptoms you're describing here but I'm not able to boot into safe mode either as I get the same error message about the megasas2.sys error

    Wednesday, June 7, 2017 9:16 PM
  • nope, I just apply the NIC driver for the Precision machines we have and then custom install the rest of the drivers. :-/
    Thursday, June 22, 2017 12:24 AM
  • Well - I thought I'd posted my update as I figured out what my issue was. The megasas2.sys drivers are all for raid cards and such, as can be deemed from their name. none of our laptops or desktops had raid cards in them, just the standard onboard ones on the motherboard. i ended up removing all instances of megasas2 drivers and nodev.inf drivers (both are by the same manufacturer, LSICorp or something like that, I forget now)

    we've had no issues since and i'm not sure why those drivers were being pulled into the image in the first place. anyways, whole crapload of headache and 2 days banging against a wall just to figure out the desktops were pulling drivers they didn't need. i didn't remove them from my winPE drivers, just the desktop and laptop drivers (total control method with mdt)\

    hope that helps! maybe you can go back and look at yours and not have to manually do it like you are :)

    Thursday, June 22, 2017 2:10 PM