Jump to content











Photo
- - - - -

ImDisk hang during DISM apply

dism hang bug

  • Please log in to reply
61 replies to this topic

#51 erwan.l

erwan.l

    Platinum Member

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

Posted 13 September 2014 - 08:48 PM

Thanks guys, now with multiple reports things are starting to get more interesting...

 
Sounds like some sanity.

Possible reasons for the weird behavior :

  • GPT
  • DiscUtilsDevio
  • ...
Next experiment asap for me : try dism with mbr disk of exact same size and configuration.

 

 

I am using imdisk only, no proxy, no discutilsdevio, no extra.

ImDisk (alone) cannot parse a GPT header, at least not with ImDisk 1.8.4 + Win7SP1. I believe it needs discutils for GPT disks.

 

But we are deviating I guess from the main topic.



#52 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 13 September 2014 - 09:57 PM

ImDisk (alone) cannot parse a GPT header, at least not with ImDisk 1.8.4 + Win7SP1. I believe it needs discutils for GPT disks.

 

Yes, there is nothing in the source for that.

In fact, Wonko gets the window of partition selection because he has a second partition defined ("1024 KB Unused"). Even if it marked as "unused", it is actually defined and so, imdisk takes this case as a multi-partitioned image file.
But the "protective MBR" is supposed to have only one partition defined (the one of type EEh that covers the larger place possible). So, it seems he is using something that does not the job properly...
Here, ImDisk is supposed to detect only one partition beginning at the sector 1 and so, to directly show the window "Mount new virtual disk". This is what you and me are getting.



#53 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2014 - 09:39 AM

Yes, there is nothing in the source for that.

In fact, Wonko gets the window of partition selection because he has a second partition defined ("1024 KB Unused"). Even if it marked as "unused", it is actually defined and so, imdisk takes this case as a multi-partitioned image file.
But the "protective MBR" is supposed to have only one partition defined (the one of type EEh that covers the larger place possible). So, it seems he is using something that does not the job properly...
Here, ImDisk is supposed to detect only one partition beginning at the sector 1 and so, to directly show the window "Mount new virtual disk". This is what you and me are getting.

Yep, this makes a lot of sense. :)

 

Though in the case of no added 00 partition, IMDISK will ONLY "autofill" the offset field (which you can edit to the proper offset) and it's still the user that clicks OK and tells it to mount the image starting at a stupid offset (LBA1) :whistling:.

 

But, on the other hand, if you supply IMDISK with a GPT disk image, and click on OK without checking what it has detected,  it will mount the 0xEE protective entry partition, and there is NO way on earth that this will get a valid filesystem mounted to a drive letter, i.e. instead of FAT, NTFS etc. it will show on the right "N/A".

 

If you apply with DISM a .wim to a non recognized filesystem it should "panic" long before reaching a meaningful percentage of applying. :dubbio:

 

@milindsmart

  1. Try forgetting EACH and EVERY attempt you did till now. :w00t:
  2. Run gdisk on the image (no reason to use a MBR disk, use the SAME GPT disk image you are using).
  3. Jolt down the offset to the GPT partition you want to mount.
  4. Open with IMDISK (the plain, simple IMDISK control panel) the image.
  5. Set the mounting offset manually to the offset you found with gdisk.
  6. Verify that you can explore the volume in Explorer.
  7. Try applying the .wim.

 

:duff:

Wonko



#54 milindsmart

milindsmart

    Frequent Member

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

Posted 14 September 2014 - 12:37 PM

@Wonko : Works.

Tried again with same image through ImDisk Toolkit mount (using DiscUtils), hangs at 74%.

Converted to MBR, works.

Culprit found ? https://discutils.co...m/workitem/5276

#55 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2014 - 01:20 PM

So, we have a "chain" that is more or less made of:

DISM->Discutils->.Net (bloat ;))->Imdisk toolkit->IMDISK

 

that once shortened to the actual "things that do the actual work without adding any auto-magic fluff":

DISM->IMDISK 

do work nicely? :unsure:

 

If this is the case :smiling9:, you can try "bypassing" the IMDISK Toolkit, though if I had to give probabilities it is more likely that it is Discutils (actually *something* in the way they "share" the contents of the image) the issue causing the DISM hang or - even worse  :ph34r: - something in the "proxy" linking. :dubbio:

 

IMDISK can use discutils "directly" using it's "proxy" feature through devio.exe, check FAQ's #7 and #8:

http://reboot.pro/to...qs-and-how-tos/

 

Your next exercises should be :w00t: :ph34r::

  1. replicate the (working) behaviour of the IMDISK control panel with command line.[1]
  2. replicate the mounting through devio.exe BUT without using the Discutils
  3. replicate the mounting through Discutils with command line and devio.exe with the current discutils
  4. try the "modified" .Net 2.0 Discutils here: http://reboot.pro/to...et-20/?p=172072

 

:duff:

Wonko

 

[1] Hint ;) run:



imdisk.exe 2>imdisk.txt

to get a full list of IMDISK command line options.

 



#56 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 14 September 2014 - 02:10 PM

So, we have a "chain" that is more or less made of:

DISM->Discutils->.Net (bloat ;))->Imdisk toolkit->IMDISK

 

"Imdisk toolkit" has nothing to do in that. Neither .NET.
But this does not prevent you to recommend a .NET 2.0 solution... :rolleyes:

 

Anyway, I have found at least one possible cause: the volume size used by DiscUtilsDevio is incorrect for GPT images.
In a GPT image file, I created a partition of 100 MB, that is, 104857600 bytes. It's exactly the value I get with my "ProxyCrypt", which handles image files partitioned in GPT.
However, DiscUtilsDevio reports:
Used size is 104857088 bytes
It lacks 1 sector.

I made the same test for an image file with MBR, and DiscUtilsDevio reports the correct size.

 

In a GPT partition entry, the last LBA is inclusive. This is a common trap for calculating the total size...



#57 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2014 - 02:54 PM

Yep :), but still it is strange. :unsure:

 

I mean, even if *somehow* a sector is missing, it can be either first sector or - more likely - last sector (I doubt that Discutill "drills a hole one sector in size" around the middle or 3/5 of an image ;)).

 

If it is first sector, the volume cannot obviously be mounted at all.

 

If it is last sector, it is usually meaningless:

  1. IF the last sector is that of the partition, then it is the NTFS $BootMirr <- and there should be no reasons why it is touched
  2. IF the last sector actually belongs to the volume it is unlikely - unless the volume is filled up to the brim - that it will be accessed, and - even if ti will be accessed/needed - this should happen with the progress at 99.99%

 

milindsmart could check if - by any chance - his image size gives space for a "twilight zone number of sectors":

http://reboot.pro/to...ated-with-dsfo/

http://reboot.pro/to...-dsfo/?p=166592

and if not, purposedly create one such "zone", or if it does, change size as to avoid one

 

But I believe the issue is somewhere else (still inside Discutils IMHO) :dubbio:

 

 

:duff:

Wonko



#58 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 14 September 2014 - 03:44 PM

It would not be surprising that NTFS relies on the size of the volume for some operations. So, with an incorrect size, sooner or later a bug occurs, creating a weird request that leads to a crash of the proxy and/or the DiscUtils library.

The description made in the post #1 is typically what we can see in this case: a proxy which no longer answers to the requests.


  • milindsmart likes this

#59 erwan.l

erwan.l

    Platinum Member

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

Posted 14 September 2014 - 03:53 PM

"Imdisk toolkit" has nothing to do in that. Neither .NET.
But this does not prevent you to recommend a .NET 2.0 solution... :rolleyes:

 

Anyway, I have found at least one possible cause: the volume size used by DiscUtilsDevio is incorrect for GPT images.
In a GPT image file, I created a partition of 100 MB, that is, 104857600 bytes. It's exactly the value I get with my "ProxyCrypt", which handles image files partitioned in GPT.
However, DiscUtilsDevio reports:
Used size is 104857088 bytes
It lacks 1 sector.

I made the same test for an image file with MBR, and DiscUtilsDevio reports the correct size.

 

In a GPT partition entry, the last LBA is inclusive. This is a common trap for calculating the total size...

 

About the size, when mounting my GPT disk in ImDisk, i initally was manually filling the offset  and the size.

Then I decided to fill in only the offset, leaving the "erroneous" size=4294967295.

Well ImDisk did not care much and mounted my partition fine.

Which is finally no surprise as ImDisk probably uses the size from the PBR.

 

Not sure it is meaningfull, but I thought I would add this detail.

 

As a whole, why would one use a proxy or discutils next to ImDisk when ImDisk can mount a partition fine (within a GPT disk) provided you know the offset?

I guess the answer is in my question : purposedly to not have to deal with the GPT header?

It would not take much to add a GPT parser to ImDisk.



#60 v77

v77

    Silver Member

  • Team Reboot
  • 602 posts
  •  
    France

Posted 14 September 2014 - 04:17 PM

About the size, when mounting my GPT disk in ImDisk, i initally was manually filling the offset  and the size.

Then I decided to fill in only the offset, leaving the "erroneous" size=4294967295.

Well ImDisk did not care much and mounted my partition fine.

Which is finally no surprise as ImDisk probably uses the size from the PBR.

 

I just made a similar test: a 6 MB volume inside a 10 MB image file. Yes, I get a drive letter with a 6 MB volume, but...
imdisk -l -u 2
Drive letter: F
Image file: \??\R:\partition.raw
Image file offset: 1114112 bytes
Size: 12884901888 bytes (12 GB), File Type Virtual Disk, HDD, Modified.


The size reported by Windows is the one detected by the file system driver. For instance, if the file system is unrecognized, the size will be 0, not the actual size of the volume.



#61 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 September 2014 - 04:29 PM

About the size, when mounting my GPT disk in ImDisk, i initally was manually filling the offset  and the size.

Then I decided to fill in only the offset, leaving the "erroneous" size=4294967295.

Well ImDisk did not care much and mounted my partition fine.

Which is finally no surprise as ImDisk probably uses the size from the PBR.

 

Well, actually that would be the actual filesystem recognizer that accesses part of what IMDISK addresses anyway.

 

The thing that gets a drive letter is the "right size" because it is derived from the BPB of the PBR, but it is read there NOT by Imdisk, but rather from the filesystem driver.

 

IMDISK reads the size from the MBR.

 

If you try (in IMDISK) to format the "target" you won't get "good" results.

 

Try playing with the attached morethanafloppy images (try re-formatting from IMDISK the one and the other :whistling:).

Check the capacity of each, before and after the formatting in IMDISK.

Then try again, re-extracting the untouched images from the .zip, using the FORMAT command in a Cmd prompt ;).

 

:duff:

Wonko

 

P.S.: Sorry v77, cross-posting.

Attached Files



#62 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 September 2014 - 03:30 PM

Anyway, I have found at least one possible cause: the volume size used by DiscUtilsDevio is incorrect for GPT images.
....

In a GPT partition entry, the last LBA is inclusive. This is a common trap for calculating the total size...

Just for the record, fixed in IMDISK and newish discutils.dll:

http://reboot.pro/to...-news/?p=187605

 

:duff:

Wonko







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

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users