Jump to content











Photo

Windows 8.1 (UEFI Boot) Issues


  • Please log in to reply
248 replies to this topic

#176 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 August 2014 - 03:24 PM

I had argued several times that this is fundamentally unsafe due to the possibility of operating system errors causing the capture operation to fail, but Simon seems confident that it will, in practice, be reliable enough to be considered "safe".

Yep :), it is not something I would like to experience in the very remote case of an OS hiccup :ph34r: 

 

:duff:

Wonko



#177 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 18 August 2014 - 09:41 AM

@Safety Concerns

 

If you want to be safe, you can use an Undo Disk, in which case on-the-fly deletion is not performed at all.

 

However if you are running out of disk space and do not have an external storage available, in that scenario, it is very convenient to be able to process a disk on-the-fly.

 

That's the whole point of compression, in fact, when you're running out of disk space :)



#178 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 18 August 2014 - 09:49 AM

@Snatch Request

 

You could probably do it in just a batch file - I'm not that well versed in batch file authoring, I didn't even realize they accepted tokens and for loops until recently :D

 

You really don't need a custom EXE for that - just copy files over from the real system to a mounted WIM or similar. I wouldn't even know the command line parameters necessary to do that with either WIMLIB or WIMGAPI command line front-ends - that's what happens when you are an API programmer, its just more convenient to call API's sometimes.

 

OTOH sometimes there's things like callbacks and processing done on API callbacks for which you simply must have your own software...and it would be very gratifying for me (egoistically) to have someone who told me outright that he wouldn't touch software I built with even a stick, to actually use a tool that I would have built. Anyways, let's not fall into egotism again, so if there is a real need for a custom EXE, I would be happy to oblige.



#179 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 18 August 2014 - 10:50 AM

@Safety Concerns
 
If you want to be safe, you can use an Undo Disk, in which case on-the-fly deletion is not performed at all.
 
However if you are running out of disk space and do not have an external storage available, in that scenario, it is very convenient to be able to process a disk on-the-fly.
 
That's the whole point of compression, in fact, when you're running out of disk space :)

Well, yes and no.
No matter how good is the OS or the program you use for compressing the disk (or *any* other program doing *any* task on the system) *something* may go wrong before or later (actually Murphy's Law tells us that it will go wrong).

Of course people is perfectly free to go around without tested and working backups and/or images of the system they are running, but it is important that they know about it.
But ... then, why?

:duff:
Wonko

#180 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 18 August 2014 - 01:48 PM

*Now* you're telling me you like Babylon 5?

 

Yes, the risk is still there - mainly from unexpected power loss - that is why I have classified DoubleSpace risk as None when an Undo Disk is being used, and Very Low when an Undo Disk is not being used.

 

In my own development testing, failures have occurred without an Undo Disk only when I had software bugs, or only when there were some unexpected problems with WIMGAPI cropping up. I have actually *never* had problems using WIMLIB to create the WIM image (WIMGAPI seems a lot more temperamental than WIMLIB), so that's another reason why WIMLIB is always used by DoubleSpace to create WIM images.

 

Bullet-proof. Software Kevlar :)



#181 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 19 August 2014 - 04:25 PM

I had some time today to put together a nice free EXE tool for anyone who wishes to extract and/or update a pre-extracted copy of WinRE 5.0 to include the WoF driver and the updated WIMGAPI libraries. This is pretty much the same code base that DoubleSpace uses, but I have not tested it as extensively as DoubleSpace, so don't hesitate to let me know if you run into any issues.

 

Download at: www.zipmagic.co/zipmagicwinre.7zip

 

Usage:

ZIPmagic WinRE Update Utility (www.zipmagic.co)
Copyright© 2014 Simon King. All rights reserved.

     Usage: zipmagicwinre.exe <filename> [-x] [-u]
<filename>: Path to WIM file, deleted if found
         x: Find and extract WIM from WinRE partition
         u: Update WIM (image index 1) with WIMGAPI libraries and WoF driver
 

Examples:

 

zipmagicwinre c:\test.wim /x

This command just extracts the WinRE WIM found on your PC.

 

zipmagicwinre c:\test.wim /u

This command just updates the WinRE WIM file at the specified path.

 

zipmagicwinre c:\test.wim -x -u

This command extracts and updates the WinRE WIM found on your PC.

 

Example output:

 

ZIPmagic WinRE Update Utility (www.zipmagic.co)
Copyright© 2014 Simon King. All rights reserved.

Querying local volumes...5 found.
Scanning volume \\?\Volume{b6b70d42-39c8-4785-bf58-9a69d5a25759}\...
Scanning volume \\?\Volume{c74127fc-1766-11e4-84c0-600292a6797c}\...
Scanning volume \\?\Volume{fac2f5cd-17d6-43e4-bc2d-0fda695a74e7}\...
Scanning volume \\?\Volume{180d2c75-15e8-4e6d-8c24-66fc7a0be837}\...found!
Copying WinRE to c:\test.wim...success!
Extracting registry from WIM...
Updating extracted WIM registry...
Updating SYSTEM registry hive...
Updating SOFTWARE registry hive...
Adding new files and updated registry to WIM...
Adding C:\windows\system32\wimgapi.dll...
Adding C:\windows\system32\wimserv.exe...
Adding C:\windows\system32\drivers\wimmount.sys...
Adding C:\windows\system32\drivers\wof.sys...
Adding C:\windows\system32\woftasks.dll...
Adding C:\windows\system32\wofutil.dll...
Adding C:\windows\system32\en-US\wof.sys.mui...
Adding C:\windows\system32\en-US\WofTasks.dll.mui...
Adding C:\windows\system32\en-US\wimgapi.dll.mui...
Adding C:\windows\system32\WimBootCompress.ini...
Adding SYSTEM registry hive...
Adding SOFTWARE registry hive...
Saving changes to WIM...
Successful updating WIM with WoF driver and new WIMGAPI!

 

Remarks:

 

You must run from an elevated command line prompt.

You must run on Windows 8.1 with Update 1.

I have uploaded only a 64 bit build. A 32 bit build will be made available upon request.

You must extract all of the files inside the uploaded archive for the app to work.

 

Enjoy :D



#182 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 19 August 2014 - 04:33 PM

Good. :)

Cross-linking it here:

http://reboot.pro/to...e-boot-wimboot/

 

:duff:

Wonko



#183 milindsmart

milindsmart

    Frequent Member

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

Posted 04 September 2014 - 10:45 AM

Although I have mentioned it before, I have to say : amazing engineering! I read through the entire thread again, and it's entertaining, inspiring, and informative.

I have some suggestions for the WinRE-update utility, since I am sure it should go viral ASAP
  • Use reagentc /info command, instead of searching each volume. You could find the wrong winre.wim, or another file named the same by mistake.... I know it sounds unlikely for a naive user, but just like you didn't exclude the clueless from the audience of doublespace, going considerable lengths to make it seamless, don't exclude the ones who dared mess with the default arrangement
  • Alternatively, you could just parse the bcdedit output for the appropriate entry
  • I do hope it actually checks for Win8.1u1 and refuses to run otherwise
  • I do also hope that the actual locale is substituted for "en-us" when it's run on a non-default-locale setup.

About on-the-fly deletion of OS files, it's so dangerous I'm surprised it worked at all... How did Windows NOT go crashing down? Also, once you added all the unlocked files into WIMs, how did you combine them all into a final WIM? Are you using what DISM calls a CustomImage : http://technet.micro...y/dn594395.aspx (see "Perform factory-floor customizations and capture the changes")? Did you do the merging before rebooting into RE or after?

Edited by milindsmart, 04 September 2014 - 10:52 AM.


#184 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 04 September 2014 - 12:45 PM

It's generally harder to make Software Kevlar, reliant on parsing output of command line files. For this reason, I am averse to #1 and #2 above, my method seems far more reliable. I have found it to be rather incredibly hard to access/make changes to the WinRE.WIM file in general, Microsoft has hidden in pretty well inside hidden partitions that are generally inaccessible. So in the interests of Software Kevlar, even if the wrong WIM file is picked up, the end-user smart enough to enact that would also be smart enough to realize that the logic in the auto-detection has gone wrong (just as you realized the possibility). Parsing command line output is a lot less reliable than this approach, given that the parsing may have to be totally language specific, as well as completely heuristic in the case of unknown error conditions. There is a BCDEDIT API, but it is absolutely horrid - it is not a Win32 API but a COM based nightmare. I don't even know if there is a REAGENTC API, but my hunch is it would be equally horrid and undocumented at best.

 

As for your other points, yes, the code is language smart - at least where it comes to adding files into the image from the correct language folders. Software Kevlar, I really like this phrase  :)

 

I do not actually have a check for Windows 8.1 Update 1...Software Kevlar is not designed to run in Venus, where the atmospheric pressure is crushing!!! I'd love to see pastes of how the code runs on other OS's, of course :D



#185 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 04 September 2014 - 12:47 PM

Next steps for this project: How about making a Recovery USB stick from this WinRE.WIM file?

 

What would the steps require for that?

 

How would the stick need to be formatted? FAT32 OK? NTFS doesn't work to boot UEFI PC's, for example.

 

Again, Simon King desires to have a one-click method to make a Recovery USB stick from the pre-existing WinRE.WIM, that'll work on x86, x64, UEFI, and BIOS - all automatically, and seamlessly.

 

Spread out your thumbtacks, Microsoft...its blood time!


  • devdevadev likes this

#186 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 September 2014 - 02:16 PM

What would the steps require for that?

 

How would the stick need to be formatted? FAT32 OK? NTFS doesn't work to boot UEFI PC's, for example.

There shouldn't be any issues, but doesn't recoverydrive.exe (already cited), starting from here:

http://reboot.pro/to...ssues/?p=185178

 

work nicely?

(maybe you missed it :unsure: as you were focused on making a WinPE at the time)

 

:duff:

Wonko



#187 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 04 September 2014 - 02:22 PM

Hmmm, looks like that is nice. But I'd need a programmatic way to do it.



#188 milindsmart

milindsmart

    Frequent Member

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

Posted 04 September 2014 - 02:27 PM

Run recoverydrive.exe silently(by whatever means necessary), redirect into an image file/VHD/whatever, and then apply it yourself...?

 

Honestly, it's just not required. Just use Misty's BCD generation commands, along with boot.sdi and winre.wim from the recovery partition, plus bcdboot.



#189 milindsmart

milindsmart

    Frequent Member

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

Posted 05 September 2014 - 09:09 AM

To elaborate on the external drive configuration to be able to boot on either BIOS or UEFI :

Standard MS MBR, 3 partitions :
  • FAT32, type 0xEF, containing bootmgfw.efi and BCD (pointing to boot.wim+sdi in next partition)
  • NTFS, type (whatever), ACTIVE, containing MS PBR, bootmgr, BCD, boot.sdi, boot.wim
  • (suggested) NTFS, type (whatever), containing the WIMs.
This is gathered from my reading and experience, not tested.

#190 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 05 September 2014 - 09:13 AM

Can you elaborate on #3?

As far as I had tested #2 does not boot on UEFI.



#191 milindsmart

milindsmart

    Frequent Member

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

Posted 05 September 2014 - 09:34 AM

Edited. I'm referring to a single drive with 3 partitions.

#192 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 05 September 2014 - 04:14 PM

To elaborate on the external drive configuration to be able to boot on either BIOS or UEFI :

Standard MS MBR, 3 partitions :

One FAT32 partition is sufficient for both BIOS and UEFI WinPE boot.
http://technet.micro...y/hh825109.aspx
  • devdevadev likes this

#193 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 05 September 2014 - 04:32 PM

Excellent. Does applying a WIM file to this single partition or just copying it there with some BCD magic suffice to boot?



#194 cdob

cdob

    Gold Member

  • Expert
  • 1437 posts

Posted 05 September 2014 - 06:48 PM

Does applying a WIM file to this single partition or just copying it there with some BCD magic suffice to boot?

Idea:
Copy WinRE.WIM to USB disk.

Next create boot files:
bcdboot %SystemRoot% /s e: /f ALL
And addjust bcd files
\Boot\BCD
\EFI\Microsoft\Boot\BCD

 
To create boot files, copy boot.sdi, winre.wim and adjust bcd:
bcdboot.exe %SystemRoot% /s e: /f ALL

Robocopy.exe R:\Recovery E:\Recovery /s

call :add_Winre_wim "E:\boot\bcd"
call :add_Winre_wim "E:\efi\microsoft\boot\bcd"
goto :eof

:add_Winre_wim
BCDedit.exe /store %1 /create {ramdiskoptions}
BCDedit.exe /store %1 /set {ramdiskoptions} ramdisksdidevice boot
BCDedit.exe /store %1 /set {ramdiskoptions} ramdisksdipath \Recovery\WindowsRE\boot.sdi

BCDedit.exe /store %1 /set {default} description "Windows Recovery Environment"
BCDedit.exe /store %1 /set {default}   device ramdisk=[boot]\Recovery\WindowsRE\Winre.wim,{ramdiskoptions}
BCDedit.exe /store %1 /set {default} osdevice ramdisk=[boot]\Recovery\WindowsRE\Winre.wim,{ramdiskoptions}
BCDedit.exe /store %1 /set {default} winpe Yes
goto :eof
Edited: winpe option added

Edited by cdob, 07 September 2014 - 08:15 AM.

  • devdevadev likes this

#195 milindsmart

milindsmart

    Frequent Member

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

Posted 06 September 2014 - 03:07 PM

This is the standard RAMDisk configuration of running WinPE/WinRE... @Simonking you must have done exactly this when you made the DoubleSpace WIMBoot-ifier.



#196 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 06 September 2014 - 10:36 PM

Uh-oh. Wonko the Sane, our collaboratively devised strategy is failing for this customer as you can see here:

http://www.zipmagic....ic.php?f=1&t=49

DoubleSpace would fail to find the partition only if it actually doesn't exist, which per our earlier chats, would be the case if the OEM ships the system without it, which apparently is against Microsoft regulations.

Any thoughts on how to handle this one? What's the best to do here, just ignore it because it is an edge-case?

Does the OEM get the blame here, or has Microsoft removed this requirement?

Edit: User did the install, not OEM. Is there an installation mode that would preclude creation of the recovery partition?



#197 milindsmart

milindsmart

    Frequent Member

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

Posted 07 September 2014 - 03:44 AM

It had always been a crap shoot for me in the case of window 7: it installed or did not install seemingly on a whim... A sure way to install with winre.wim was to create the partition with the appropriate type id beforehand.

With windows 8 I highly doubt it. Ask him to run reagentc /info. My guess is that its there but your tool failed to find it..

#198 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 September 2014 - 09:55 AM

The OEM is fine.

MS requirements are for the OEM, not for the end user.

How the end user re-partitions his/her system is essentially his/her problem (regarding "responsabiity") and not anyone else's.

 

What might help you help these people would be a tutorial (or documentation or automated tool, whatever) aiming at making the recovery partition "like the OEM", and or clear instructions on how to recreate that partition and copy to it the WinRE.

 

This is - more or less - the same issue as with the "old" systems used by HP and others with the "special" MBR:

 end users would replace them with the "standard" MBR and they could never be able to access again the recovery partition (obviously without having created the recovery media that the OEM should have provided, either forced by Law or by their own common sense/honesty :frusty:, instead, in order to save a few bucks, of telling the end user to create one.

 

HP was even sued and lost for this, but like many others, went ahead alright.

 

Come on :), everyone of us has bought a new model laptop/tablet (or got it as a gift for birthday or Christmas :yahoo:), you open the package and you are excited, happy, and want to play with the new stupid thingy, you don't have a set of CD's/DVD's handy, you don't want to lose a couple of hours imaging the disk or making the recovery media when you are told to make them (at first boot), and when you will need them, even in the remote case when you actually made the recovery media, it will have been chewed by your dog or lost among a zillion other UNlabeled CD's/DVD/s ( which are usually  organized in neat piles, on top of one of which there is a post-it to remember to "buy a CD felt tip and write labels" ;)).

 

The big issue with the "old" style recovery parittions was that recreating the MBR was usually a nightmare (thanks to the still demented OEM's, again like HP, that provided no or very little support) but now that there is no such "special" MBR and the procedure is "unified" there should be no issues.

 

AFAIK, if the disk is pre-partitioned at the time the Windows is installed, the partition won't be made (at least this is valid for Windows up to 7 and for the "system" and "boot" partitions - the ones that are actually "boot" and "system" - and I don't see why this should have been changed in 8/8.1 :dubbio:).

 

:duff:

Wonko



#199 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 07 September 2014 - 10:38 AM

milindsmart, thanks for the reagent command. Exactly what I was looking for, to see if this is a bug in my software or not.

 

wts, you seem to have confirmed my hunch that letting Windows create its own partitions might help, as I had already posted at my forum.

 

Thanks folks, again much appreciated.



#200 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 September 2014 - 11:38 AM

BTW, when the WinRE.WIm is not in it's own partition, it should have been created alright in the "main" (usually only) partition and the recoverydrive.exe should work as well.

And - even if *somehow* - the paths to WinRE.wim are botched, it is normally possible to "fix" the issue, like:

http://www.terabyteu...icle.php?id=587

or create manually a "recovery drive":

http://technet.micro...3(v=ws.10).aspx

the above confirms neatly the observation by Misty here:

http://reboot.pro/to...ssues/?p=185179

 

:duff:

Wonko






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users