none
MDT 8450: WIM File Corruption (5624) 1392 DISM error on applying the .WIM File RRS feed

  • Question

  • The infamous pink screen with Failure ( 5624 ): 1392: Run DISM: /Apply-Image /ImageFile:\\<Server>\<Share>\<path>\RS2_201712.wim /Index:1 /ApplyDir:D:
    This occurs on both physical and virtual computers.<o:p></o:p>

    Further Research: 1392 return from DISM is indicting WIM file corruption.  The issue is, is that I can deploy this a few times and then unexpectedly it will get corrupted.  If I copy in a fresh copy of the reference image, it works for a while.  Note: this is a image that other coworkers are using and are not having issues with it, only my environment.<o:p></o:p>

    Remediation steps: I have rebuilt the share,  I have rebuilt the server and the share, I have rebuilt task sequences...  all to no avail.  I tried disabling SMBv2/v3 as seen in another thread, to no avail. (I cant add links yet)  Disabled Windows Defender and does not resolve.<o:p></o:p>

    Basic info on my environment:
    Server OS: Windows Server 2016 (1607)
    MDT Version: 8450
    ADK Version: 1709
    Server: Hyper-V
    Server RAM: 10 GB
    Server Procs: 2 Virt Procs
    C: Drive: OS and patches, 60 GB
    D: Drive: MDT share and storage, 440 GB<o:p></o:p>

    I can post up logs fairly easily if they are needed.<o:p></o:p>

    I guess my main question is what processes on a server could corrupt a WIM file every so often?
    Friday, March 9, 2018 8:14 PM

Answers

  • Thanks all.  As I slowly slipped into insanity, I finally decided to check my physical hardware.  It seems I had a bad RAM chip in my test environment laptop.  Upon replacing that chip, I have not had any issues.  I will continue to keep this open for a few more days, but it seems like this may do the trick.

    I appreciate the suggestions and reccomendations provided in the thread.

    LawsonT


    Edit: My suspicions of the bad ram chip impacting the server was correct.  I have not had issues since swapping that out.  Resolved
    • Edited by LawsonT Tuesday, March 20, 2018 3:04 PM Update to Resolution
    • Marked as answer by LawsonT Tuesday, March 20, 2018 3:04 PM
    Monday, March 19, 2018 6:29 PM

All replies

  • Have a look at this https://social.technet.microsoft.com/Forums/en-US/aafda161-9841-45a5-aebf-8768891a7b82/dismexe-error-while-applying-unattendxml-during-lti-deployment-with-mdt-2013-reproducible-bug?forum=mdt&prof=required
    Removing the "OfflineServicing section" in the unattend-xml of the task sequence made my day.
    Monday, March 19, 2018 3:20 PM
  • 4077,

    This does not look like my issue as I am not even getting to the apply unattend.xml.

    Thanks anyway,

    LawsonT

    Monday, March 19, 2018 4:17 PM
  • Could you pull your LiteTouch.log and your dism.log from one of the failed installations and upload them to a public hosting site? There is simply not enough information here to hazard a guess.

    Cheers,
    Anton

    Vacuum Breather Blog | Wing Commander Saga | Twitter

    Note: Posts are provided "AS IS" without warranty of any kind. If posts are helpful please don't forget to rate them as "Helpful" or as "Answer".

    Monday, March 19, 2018 4:20 PM
  • Thanks all.  As I slowly slipped into insanity, I finally decided to check my physical hardware.  It seems I had a bad RAM chip in my test environment laptop.  Upon replacing that chip, I have not had any issues.  I will continue to keep this open for a few more days, but it seems like this may do the trick.

    I appreciate the suggestions and reccomendations provided in the thread.

    LawsonT


    Edit: My suspicions of the bad ram chip impacting the server was correct.  I have not had issues since swapping that out.  Resolved
    • Edited by LawsonT Tuesday, March 20, 2018 3:04 PM Update to Resolution
    • Marked as answer by LawsonT Tuesday, March 20, 2018 3:04 PM
    Monday, March 19, 2018 6:29 PM