2 replies to this topic

[spleenharvester]

I have a few USB drives here of varying model. Using a script I compile my WinPE images and Windows installers onto them, add an NT6 MBR and bootsector using bootsect.exe, then set the drive as active. So they are all compiled in the same way.

 

Sometimes, after compiling, the WinPE images will work wonderfully - but installers won't work. They are mounted via ImDisk which is called from winpeshl.ini (a bit like the arrangement in the WinSetupFromUSB project)

 

I'm not sure if this is a bug with ImDisk, but what seems to happen is the mounted drive becomes inaccessible seconds after mounting. You can still view root folders but most of the time can't go inside them. This causes setup.exe to bug out in weird ways with various errors about not being able to install, sometimes even rendering artifacts.

 

The kicker:

 

a) Everything on these drives is MD5-hashed, and the working drives have identical contents to the non-working drives.

 

b ) Performing a diskpart clean on the non-working drives, then recompiling, will usually make them work properly again. However, the problem eventually seems to reoccur.

 

I don't think it's directly something with ImDisk, possibly some kind of weird MBR issue since the MD5s were the same? Has anyone ever had this problem?

 

Happens with the latest version of ImDisk and various older versions too.

 

Cheers

Edited by spleenharvester, 27 June 2016 - 01:38 AM.

[spleenharvester]

Now one of the disks is consistently failing to mount properly even with a diskpart clean.

Edited by spleenharvester, 27 June 2016 - 02:53 AM.

[spleenharvester]

Few more clues: if I boot into the same WinPE image from either the working or non-working stick, then attempt to mount the ISO located on the non-working stick, it fails to mount properly. But if I boot from the non-working stick and then insert a working stick and mount the ISO located on that working stick, it works just fine. Both have identical MD5 hashes. Ideas?

 

The only drive that consistently works is a Lexar Jumpdrive S23 USB3.0 8GB

 

The drive that is consistently failing with the same error is a Netac OnlyDisk U235  USB2.0 16GB

 

This happens on two different computers, both EFI and legacy, both USB2.0 and USB3.0 ports

Edited by spleenharvester, 27 June 2016 - 03:52 AM.