Jump to content











Photo
- - - - -

ImDisk hang during DISM apply

dism hang bug

  • Please log in to reply
61 replies to this topic

#1 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 05 September 2014 - 08:37 AM

A possible bug in ImDisk  :D

Situation :

  • Running windows 8.1 u1 x64
  • Mounted Vista x86 SP0 ISO (wondering why?  :D ) to H: 
  • Mounted partition 3 of GPT partitioned dynamic VMDK using ImDisk Utils to letter R:
  • Formatted volume
  • Tried applying H:\sources\install.wim using dism to R:
  • Hang

This is the worst possible sort of hang, that reveals NO anomalous CPU | RAM | Disk | Network usage at all... Things seem to work normally, but trying to close some/any open applications results in freezing. CANNOT terminate any frozen process (have seen 1/2/3 such affected processes), has no effect. Ctrl+Alt+Del works, but signing out does not... Hard power off is the only option...

 

The EXACT same thing with VHD attached in Disk Management, works perfectly fine...


Edited by milindsmart, 05 September 2014 - 08:38 AM.


#2 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 September 2014 - 10:37 AM

Not a bug.

You are seemingly performing on the volume mounted through IMDISK things that you shouldn't.

(if you prefer the "bug" is more likely in DISM)

 

Try, as you were already told, to use the Arsenal driver instead of IMDISK:

http://reboot.pro/to...ement/?p=186962

 

It is very likely that DISM *needs* to access the MBR (or in the case of GPT disks the partition table).

 

Hint :unsure::

Check "sectors before" in the BPB after having formatted a volume (inside a disk) mounted with IMDISK.

Then try again after having mounted the same volume through a disk driver (such as Arsenal or Total Mounter or the like, i.e. something that shows the mounted disk and volume(s) in Disk Management)

 

:duff:

Wonko



#3 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 05 September 2014 - 12:06 PM

On the contrary, using Arsenal Disk Driver won't prove a thing about ImDisk... They have virtually nothing in common save for being created by the same developer... I'm certainly not depending on that commonality.

 

I will try Arsenal soon, but what can test your hypothesis (when i get home) is to try this with any other volume mount tool that doesn't create a virtual disk entry. I tried WinMount but it looks like it doesn't support GPT, as well as doesn't allow me to choose the partition I want.

 

Having said that, I'm quite sure that dism doesn't touch anything outside the given filesystem volume. "Sectors before" I am not sure... it makes no sense for the format tool to be modifying the value WITHOUT knowing it's position in the disk... which it obviously doesn't know because there is no backing disk for the volume.



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 05 September 2014 - 12:37 PM

It is not about commonality of same Author, it is about "level" in which the driver is "hooked".

 

Try Total Mounter (definitely different Authors) if you want to avoid (why) the Arsenal thingy:

http://www.kernsafe....talmounter.aspx

 

Unrelated to your issue, but just FYI, the "format" command in windows is a "strange beast".

 

I take for granted that you are more familiar with DOS and/or Linux behaviour.

 

In Windows NT when you format a volume (inside a "real" disk) the FORMAT command will access the MBR and - if needed - change the partition ID of the corresponding entry in the partition table.

 

As well, the "generic" Windows system will change (silently) a disk signature if it is empty 00000000 or if it duplicated at the time of mounting accessing the disk (real or virtual).

 

 

IMDISK treats a volume as if it was a "superfloppy", i.e. with it beginning on "sector LBA 0", this is not a limitation, it is by design, and if you try using on IMDISK Format. in this case. treats the volume as a superfloppy (and thus sets sectors before 0), possibly avoiding to attempt reading or writing to the MBR partition table (or corresponding GPT structure)

 

DISM may well *need* to "identify" the volume (on a disk) by a number of parameters that reside outside the volume itself, among them, as said, the Disk Signature, the offset to the beginning of the volume or equivalent data from a GPT disk, and to do this may well access areas that simply do not exist in a mounted IMDISK volume (which is also BTW "transparent" to mountvol command):

http://reboot.pro/to...disk-in-win-2k/

 

And - still just for your interest - Ken Kato's VDK driver is "half-way" in the sense that it is NOT accessible from Disk Manager BUT mounted volumes are within the Mount Manager reach (and listed in mountvol):

http://reboot.pro/to...l-ufd/?p=151130

 

Also, as Olof said:

http://reboot.pro/to...twist/?p=162458

 

If you prefer :), while there is no doubt that you experienced an issue :( when using DISM on a IMDISK mounted volume, you were IMHO a tadbit too fast to call it a "possible bug in IMDISK", it is more likely that you are using a tool outside it's usage paradigm.

 

:duff:

Wonko



#5 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 06 September 2014 - 09:09 AM

As usual you make sense Wonko. There are multiple aspects you brought up.

  • You're probably right about format, the "sectors before" would probably have doomed the attempt at the start itself
  • Treating it as superfloppy is the right thing to do when only a single volume is mounted on the device. so there is NO question of format command trying to change the partition type in the MBR partition table. Besides, there was no change in the partition type in this case when I formatted.
  • Same thing applies to disk signature, dism would not have bothered about it because the volume was a superfloppy. Instead the NTFS volume signature would/should/has to suffice.

The funny thing, however, is that it stalls at 10% or 11%... not at the beginning, not at the end.



#6 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2014 - 09:41 AM

Besides, there was no change in the partition type in this case when I formatted.
Same thing applies to disk signature, dism would not have bothered about it because the volume was a superfloppy. Instead the NTFS volume signature would/should/has to suffice.

Yes :), but you have to understand how this is "normal", in the sense that it is not like "format did not change partition type" (and the same applies for disk signature).

The MBR access is *connected* to disk manager and to mount manaager, IMDISK volumes are simply "transparent" to both.
As well, disk signature is *connected* to disk manager and to mount manager, IMDISK volumes are simply "transparent" to both.
Additionally to that, *anything* before the PBR, simply does not exist in a IMDISK mounted volume (as the volume, by definition, has a PBR as first absolute sector).

It is rather common (I do it often for tests, since IMDISK - being "higher" level than more "complete" disk image drivers like the ones mentioned - is often more handy and fast for some quick mounting/formatting) to format a volume in IMDISK, then dd the volume to a "real" (or virtual) hard disk image partition and edit the "sectors before".

Consider also how the "sectors before" may be relevant for some uses of the image (like booting), but may be not relevant for other ones (like mounting).
 

The funny thing, however, is that it stalls at 10% or 11%... not at the beginning, not at the end.

Well, hard to say, but I wouldn't be surprised if DISM "prepares" a few things, let's say that it scans the target to make a list of the files that won't be replaced (or however does some data collection or whatever), and only after this preliminary part attempts accessing *something that is not there* or uses for the first time an API function (or whatever) that throws the error.

:duff:
Wonko



#7 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1986 posts
  • Location:Nantes - France
  •  
    France

Posted 06 September 2014 - 11:25 AM

Similar discussion here around ImDisk and PBR.

My conclusion back then being "ImDisk is perfect for what it does : mount volumes".

Note that I use the word "volume" to avoid confusion (again) around drive/logical, etc ...

 

If one need to emulate a physical disk, then defo, the answer is the arsenal drive or the native/builtin VHD feature of Windows.



#8 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 06 September 2014 - 11:37 AM

If one need to emulate a physical disk, then defo, the answer is the arsenal drive or the native/builtin VHD feature of Windows.

 

Or - depending on the actual Windows version - the MS VSS drivers, or Total Mounter ..... 

 

But again - within some limits - the Ken Kato's VDK driver still goes strong :).

 

Which reminds me about the fact that the "mother of all ramdisk filedisk topics" :w00t: has not been updated with the Arsenal Mount driver:

http://reboot.pro/to...ledisk-drivers/

 

Will do. :)

 

:duff:

Wonko



#9 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 08 September 2014 - 07:30 AM

Hint :unsure::

Check "sectors before" in the BPB after having formatted a volume (inside a disk) mounted with IMDISK.

Then try again after having mounted the same volume through a disk driver (such as Arsenal or Total Mounter or the like, i.e. something that shows the mounted disk and volume(s) in Disk Management)

 

I checked : it shows 00 28 03 00 => 0x32800 => 206848 (sectors) => (*512=) 105,906,176 B => 103424 KiB => 101 MiB . This is correct.

 

It's the same with Arsenal. Remember, this was after I formatted it, twice, so evidently windows doesn't touch the field even when the volume is mounted as a superfloppy.

 

But the original point of this thread remains : it's a bug...

 

I have a perfect way to test it : point me to another (disk-image -> single partition -> volume) mounter... if the same error occurs, then we know you're right, else I'm right :)



#10 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1986 posts
  • Location:Nantes - France
  •  
    France

Posted 08 September 2014 - 08:25 AM

Interestingly, I get different results.

 

When I format a volume thru ImDisk, I always get hiddensec=1 (in the PBR) which prevent that image to boot unless I fix this field.

This is what I reported in previous post.

Thus as explained by Wonko, this is not surprising as from ImDisk p.o.v, there is nothing before the PBR (although the value 1 is discussable).

 

When formating my volume thru Arsenal, I get hiddensec=2048, matching my sectorsbefore field (in the MBR).

 

But as a whole i'd say you cannot compare ImDisk which is a volume driver to other disk drivers (vss, vdk, vhd, arsenal, etc) when it comes to aspects related to the disk part (mbr, sectors before, etc).



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 September 2014 - 09:06 AM

I have a perfect way to test it : point me to another (disk-image -> single partition -> volume) mounter... if the same error occurs, then we know you're right, else I'm right  :)

Try the "father" of ALL filedisks (which - surprisingly :w00t: - is actually called "filedisk" ;)):

http://www.acc.umu.se/~bosse/

 

It is a lot of time I don't actually use it, but it mounts volumes and not "whole disks" (though the actual level of its "hooking" in the OS is to be checked).

At the time I went for VDK because filedisk didn't have the "right" kind of integration I needed.

 

:duff:

Wonko



#12 v77

v77

    Silver Member

  • Team Reboot
  • 525 posts
  •  
    France

Posted 08 September 2014 - 12:02 PM

As I am a bit slow-witted, I just started to understand the issue described here. So, I will try to explain that with my own words.

The type of a partition is not only determined by its file system, but also with some data located in the MBR or GPT.
When you mount a partition with ImDisk, this latter gives you only access to the data of the partition, not the rest (because it only mounts volumes). And so, if you format this partition, the GPT may not be modified as it should, and so, there can be some conflicts later.

In fact, I wonder what is the field of GPT that could require a change, perhaps the "Unique partition GUID"...

Anyhow, I am sure that everything is working fine. Formatting a partition is not the same than formatting a volume, because of the informations of MBR/GPT that may require changes.

And that's why Wonko endlessly repeats that it's important to make the difference between disk, partition and volume.



#13 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 08 September 2014 - 12:38 PM

Interestingly, I get different results.
 
When I format a volume thru ImDisk, I always get hiddensec=1 (in the PBR) which prevent that image to boot unless I fix this field.
This is what I reported in previous post.
Thus as explained by Wonko, this is not surprising as from ImDisk p.o.v, there is nothing before the PBR (although the value 1 is discussable).


I was wrong :

I checked : it shows 00 28 03 00 => 0x32800 => 206848 (sectors) => (*512=) 105,906,176 B => 103424 KiB => 101 MiB . This is correct.
 
It's the same with Arsenal. Remember, this was after I formatted it, twice, so evidently windows doesn't touch the field even when the volume is mounted as a superfloppy.
 
But the original point of this thread remains : it's a bug...
 
I have a perfect way to test it : point me to another (disk-image -> single partition -> volume) mounter... if the same error occurs, then we know you're right, else I'm right :)

 
Sorry it must have been a mistake : I am able to reproduce the behavior you're talking about.  So the next step is to see if dism needs to access the MBR for normal running.

#14 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1986 posts
  • Location:Nantes - France
  •  
    France

Posted 08 September 2014 - 01:49 PM

I was wrong :

 
Sorry it must have been a mistake : I am able to reproduce the behavior you're talking about.  So the next step is to see if dism needs to access the MBR for normal running.

 

 

Well actually it might not be related to the MBR but to an API not supported by the imdisk driver.

For example, ImDisk will not provide a volume GUID (this was discussed here on this forum).

Nor will it provide a dosdevice name (in the form of \device\hardiskX\partitionX)see here.

 

So these facts could also explain why DISM hangs when applying a WIM with ImDisk.


  • milindsmart likes this

#15 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 08 September 2014 - 02:56 PM

@v77

Almost :), but not quite. :w00t:

 

The data that is in the MBR (or in the GUID) is *just* 3 (THREE) things, of course written differently, and in the case of CHS/LBA twice:

  1. the ID of the partition (though I have written this n times, it is not fully "absorbed", since the opposite has been believed for years - and BTW I also used to believe this - that the partition ID is ONLY a "protective ID")
  2. the start address of the partition
  3. the number of sectors of the partition

The particular implementation of the FORMAT command on Windows NT also checks that the ID in the partition table is "suitable" for the filesystem used. <- this is actually a "flawed" or "old time" setting.

 

Experiment for the day.

  1. (Obviously in a VM) make a small bootable partition (a bootable MBR, a bootable bootsector and either NTLDR+BOOT.INI or BOOTMGR+\boot\BCD would do fine).
  2. Format it as FAT(16).
  3. Check it boots.
  4. Check that in the MBR the partition ID is set to 06 or 0c.
  5. Re-format the partition (re-adding the bootfiles) as NTFS.
  6. Check it boots.
  7. Check that in the MBR the  partition ID is now 07.
  8. Hex edit the partition ID to 06.
  9. Try booting.

 

On the other hand, nowadays 07 can mean NTFS, exFAT and even UDF, so the link (if ever there was one) between partition ID and filesystem type is nowhere to be seen,

 

But - more generally - when you format a volume (mounted in IMDISK) the FORMAT command - as said - does not attempt to touch the "non existing" MBR.

 

And by formatting you don't actually change the start address of the partition or the number of sectors that constitute it's extents.

 

So you have to distinguish between:

  1. formatting with a new filesystem that is not the same as the one that was there before (and which partition ID is NOT among the ones Windows 7 recognizes)
  2. all other cases

 

An example of #1 you may want to re-format under a Windows NT an Ext3 formatted volume (with a partition ID of - say -83) in NTFS.

After the formatting "through" IMDISK you will need to correct the partition ID in the MBR (and if you want to actually boot from it you may need to correct sectors before).

 

Second experiment for the day :ph34r::

  1. use (say) Total Mounter (or other "full disk" driver) and create a new smallish hard disk, let's say 20 Mb in size
  2. open disk management, you will be asked to initialize the disk (do it)
  3. then create a new primary partition on it (bit DO NOT format it from within disk manager)
  4. check the MBR what partition type (if any) is set in the (only) entry?

@erwan.l

Sure :), it could be a missing API, the "final statement" here is that there is *something* that is missing and *whatever* it is, it makes IMDISK not suitable for *anything* not strictly volume/filesystem related (but - on the other hand this "different level" of "hooking" in the OS, makes it very fast at mounting volumes and more generally very convenient for the uses that are suited).

 

 

:duff:

Wonko

 

 

 

 



#16 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 10 September 2014 - 06:51 AM

Try the "father" of ALL filedisks (which - surprisingly :w00t: - is actually called "filedisk" ;)):

http://www.acc.umu.se/~bosse/

 

filedisk does not seem to support VMDKs. Can I use DiscUtils to export a proxy and use that?

 

Edit : now trying with VHD on ImDisk, hoping its raw characteristic will let it work on filedisk.

update : it showed milder symptoms but still went into an unrecoverable state at 72%...

 

Wonko, over to you : please suggest step-by-step, a proper set of tests. You're good at this stuff. Also, please try to verify.

 

P.S.: Maybe this is the time to try all this in a VM?



#17 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2014 - 07:41 AM

filedisk does not seem to support VMDKs. Can I use DiscUtils to export a proxy and use that?

 

Edit : now trying with VHD on ImDisk, hoping its raw characteristic will let it work on filedisk.

Well, filedisk expects a non-partitioned image (or if you prefer a super-floppy or a "volume").

 

As always, you cannot first ignore what is being told you and later ask about the SAME thing when your attempts using something outside it's usage paradigm fail:

 

It is a lot of time I don't actually use it, but it mounts volumes and not "whole disks" (though the actual level of its "hooking" in the OS is to be checked).

 

Ken Kato at the time got inspiration from it to write the VDK driver that can deal with partitioned images (RAW, or through .PLN or early versions of VMDK's).

 

To sum up (again):

  • Arsenal Mounter, Total Mounter, the VSS drivers can mount "whole" hard disk images as hard disks AS if they were hard disks
  • VDK driver can mount  "whole" hard disk images as hard disks AS if they were hard disks BUT without a "connection" to Diskpart or Disk Manager
  • Imdisk can mount ONLY volumes that can reside inside a "whole" hard disk image (given that the proper offset is given)
  • filedisk can mount ONLY volumes (and the image needs to be a volume or partition image)

I doubt that filedisk can mount through a proxy :dubbio: but "mixing" a conceptually very old driver with discutils and the .Net madness doesn't seem to me anyway a good idea :ph34r:.

 

:duff:

Wonko



#18 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 10 September 2014 - 07:59 AM

Oops... I'm missing many minor details these days. Anyway, what do you suggest must be done to test if this "bug?" is really a bug or not? Should I try with VDK? I feel that would unnecessarily widen the scope of testing this bug, because it's not similar enough to ImDisk in its mechanism.

 

What we do know at this point is something goes wrong when using dism on a volume mounted by ImDisk, whether VMDK or VHD, which sort of rules out it being a DiscUtils bug.



#19 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2014 - 08:12 AM

  1. Make a very small image (a simple file, 20 Mb would be fine).
  2. Mount it in 1) Arsenal Image mounter or in 2) Total Mounter or with the 3) VSS drivers.
  3. Partition/format it with a single partition/volume through diskpart or disk manager.
  4. Copy inside it a bunch of sample files.
  5. Make a .wim image of it's contents with DISM (or wimlb)
  6. Re-format it.
  7. Unmount it.
  8. Make a copy of it.
  9. From the copy extract just the partition/volume (i.e. make a copy starting from an offset to the PBR).
  10. Try mounting this extracted volume image in filedisk (see if you need to correct sectors before, but in theory it should not be needed)
  11. Make a copy of this volume image.
  12. Try  applying to this - mounted in IMDISK volume image - the .wim with DISM (or wimlib)
  13. Try  applying to this - mounted in filedisk volume image - the .wim with DISM (or wimlib)
  14. Try applying to the copy of the WHOLE image - mounted in 1) Arsenal Image mounter or in 2) Total Mounter or with the 3) VSS drivers - the .wim with DISM (or wimlib)

Differences in what happens between #12 and #13?

Differencesin what happens between #13 and #14?

Differences in what happens between #12 and #14?

 

Also, do check the link provided by erwan.l here:

http://reboot.pro/to...ly/#entry187113

 

 

:duff:

Wonko



#20 erwan.l

erwan.l

    Gold Member

  • Developer
  • 1986 posts
  • Location:Nantes - France
  •  
    France

Posted 10 September 2014 - 10:58 AM

Oops... I'm missing many minor details these days. Anyway, what do you suggest must be done to test if this "bug?" is really a bug or not? Should I try with VDK? I feel that would unnecessarily widen the scope of testing this bug, because it's not similar enough to ImDisk in its mechanism.

 

What we do know at this point is something goes wrong when using dism on a volume mounted by ImDisk, whether VMDK or VHD, which sort of rules out it being a DiscUtils bug.

 

I believe the "container / format" does not play a part in your issue : raw img, vmdk, vhd, etc or any formats (proxyed or not) thru ImDisk should always generate the same "bug" (if we can call it a bug).

 

The thing is that DISM needs "something more" than ImDisk cannot provide.

Strange as DISM should be working at the partition level only but DISM remains a black box (when ImDisk is not).

 

Note about proxies : if you look under ImDisk sub forum, you should find "native" imdisk proxies for VMDK and VHD not requiring .Net (shamelessly doing some publicity for myself B)  ).

These are read only thus, so useless for the dism /apply stage.

 

Second note about a proxy : using devio (goes with ImDisk), you might be able to get a bit more informations around which offset DISM is freezing.



#21 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 10 September 2014 - 04:58 PM

Differences in what happens between #12 and #13?

Differencesin what happens between #13 and #14?

Differences in what happens between #12 and #14?

 

They all work perfectly... 

 

BTW filedisk seems to just barely work on my Win 8.1u1 ... the created volume (drive letter) was not visible in Explorer, only on command line... nevertheless, dism worked.

 

Next : MD5 hash verification?



#22 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 10 September 2014 - 05:09 PM

Next : MD5 hash verification?

Verification of what?

 

You started this thread about IMDISK not working with DISM and now (#12) it works fine, if I get it right.

 

What has changed from your previous test?

What is the difference (if any) is there between the "superfloppy" image mounted in IMDISK (that works) and the "whole disk image" mounted in IMDISK with the appropriate offset? 

 

Can you try this latter and confirm that it still works like the "superfloppy" image? (or it fails as in your "full scale" initial test?)

 

Let's call it #15:

15. Try applying to the copy of the WHOLE image - mounted in 4) IMDISK - the .wim with DISM (or wimlib)

 

Maybe it makes a difference with autodetect with "auto", "hard disk volume" "floppy", etc.?

 

 

:duff:

Wonko



#23 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 10 September 2014 - 06:07 PM

15. Try applying to the copy of the WHOLE image - mounted in 4) IMDISK - the .wim with DISM (or wimlib)

 

Works perfectly.

 

I doubt autodetect makes a difference, since it will eventually initialize with the correct option...

 

So next would be full-scale test with the same variations?



#24 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13752 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 September 2014 - 11:04 AM

So next would be full-scale test with the same variations?

Yes, but it would - to say the least - "queer" that the issue is connected with size/number of files. :dubbio:

If this is the case the oly logical explanation would be that over a given size some "resources" of *some kind* (a cache, a buffer, *something*) bombs out.

 

Maybe the issue is with some "special" structure (like hard links or similar) in the "source"? :unsure:

Or with the "applying" of particular files? (but what could that be?)

Maybe you can try using a boot.wim/WinRE.wim to make a small "flat" PE, then capture it and retest the applying?

 

:duff:

Wonko



#25 milindsmart

milindsmart

    Frequent Member

  • Advanced user
  • 201 posts
  • Location:Bangalore
  •  
    India

Posted 11 September 2014 - 11:14 AM

Just now I extracted the partition alone from a VHD to a file, mounted it on ImDisk, and successfully applied the Vista install WIM on it. I hadn't even corrected the sectors before.

 

Rules out something wrong with this particular ISO/WIM.







Also tagged with one or more of these keywords: dism, hang, bug

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users