Jump to content











Photo

Windows 8.1 (UEFI Boot) Issues


  • Please log in to reply
248 replies to this topic

#151 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 14 July 2014 - 07:32 PM

Yes, good question. This particular bug I defused by discovering that in fact, the WIM file I was booting from was not the WinRE WIM, but a full disk image that I was running off of live.

 

So your question is really good; because it nails the issue head-on. This issue has been resolved.

 

The other Surface had lost its boot menu from GUI to Text, possibly courtesy of Paragon disk imaging tools. I ended up using Macrium to revert it to a generic Surface installation image, installed Windows 8.1 Update 1 on it, and then DoubleSpace ran perfectly fine on it :)

 

The goal is realized - free for all to try at www.zipmagic.co/zipmagic.msi - I've already gotten a request for a key, don't hesitate to PM.



#152 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 10 August 2014 - 09:09 AM

OK, the Surface booting menace is back.

 

I have a customer who has successfully used DoubleSpace, but he also experiences the infamous boot stalls that I have seen on some of my Surface's.

 

Fortunately in his case, the delay he experiences is only 2 minutes instead of the 20-30 that I was having on mine. However, this 2 minute delay was sufficient to turn him off using DoubleSpace entirely, and I wouldn't blame him for that. I will soon as him whether he can also reproduce the boot delay using things that created it for me using things like VHD boot. I've also asked him already whether he's used any kind of disk imaging software to date.

 

Regretfully, I am still clueless about these UEFI boot issues - that I had originally opened this thread about. Are there any diagnostics I could send my customer, and/or use on my own affected systems, to finally nail this issue down?

 

And the circle is complete, I suppose, with this thread returning to where it started.



#153 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 12 August 2014 - 07:16 AM

Anyone?

 

Is there any way to diagnose why a Windows 8.1 system would "stall" for anywhere between 2 minutes to 30 minutes before showing the boot spinner, without any other indication of what might be going wrong?

 

And, without a way to reproduce in a VM, of course?



#154 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 12 August 2014 - 01:58 PM

Well if you can replicate the issue in a VM, then yes. You would need to test on a system showing the boot delay. See here:
http://www.msfn.org/...ernates-slowly/

#155 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 12 August 2014 - 02:01 PM

Trip, I've already mentioned that the issue does not replicate on a VM. At least, I don't know how to replicate it - and I have a feeling I won't be able to replicate it until I actually find out what causes it! Which is the whole point of the exercise :)

 

Thanks for the link. I'll ask my customer to check it out and provide a trace.



#156 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 14 August 2014 - 08:53 AM

OK, another question - this one is WinRE related.

 

Has anyone figured out what the minimum set of updates required for the WoF driver are?

 

Currently with the WinRE approach, a significant drawback is because the WoF driver is not installed on WinRE - even if the system was installed brand-new with Windows 8.1 Update 1 (and I tested with both factory fresh Surface Pro 3's and VM installs of Windows 8.1 with Update 1 included officially by Microsoft [from MSDN]), this is the case.

 

So the problem is, when it is time to recompress a drive that has already been compressed by DoubleSpace, the recompression fails because the WoF driver does not serve actual file data - hence, one must again manually and laboriously create a Windows PE with Windows 8.1 Update 1 applied.

 

Simon again slams his hand on the table demanding the best possible user experience for his customers...so short of downloading a ~800 MB update from Microsoft and patching up the extracted WinRE image using DISM; is there a more practical approach? Could the WoF driver simply be "snatched" from the existing image, and the WinRE image patched to include the WoF driver?

 

I suppose there'd be no legal concern with that, since we'd be taking WoF from a system it already exists on...

 

In the meanwhile, I continue to await a trace from the customer for the slow booting issue.



#157 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 August 2014 - 10:07 AM

Simon again slams his hand on the table demanding the best possible user experience for his customers...so short of downloading a ~800 MB update from Microsoft and patching up the extracted WinRE image using DISM; is there a more practical approach? Could the WoF driver simply be "snatched" from the existing image, and the WinRE image patched to include the WoF driver?

Simon should be aware that the good MS guys did intentionally spread a number of thumbtacks on the table where he repeatedly slams his hand. :whistling:

 

AFAIK the needed files can be "snatched" fine from the installed OS but the WinRE image needs to be serviced anyway via DISM or wimlib.

Files/Registry settings are tentatively listed here:

http://reboot.pro/to...mboot/?p=183981

though nothing "definitve" or "working".

 

I believe it is also possible to find out in which of the 6 files actually composing the stupid Update 1 the relevant files are and do a partial download,/custom extraction, but  don't think anyone has tried doing that (or reported about doing it) here are the links if anyone is interested in the experiment:

http://www.mydigital...ownload-center/

 

:duff:

Wonko



#158 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 14 August 2014 - 10:25 AM

My task is a little easier, I don't need to WIMBoot, nor do I need to have this run on any OS older than PE 5.0.

 

All I need is actually to have the files be served from WinRE which is, by the sights of it, PE 5.0.

 

By having the files served, I mean, having the WoF driver loaded and active - otherwise, file contents are inaccessible on a WIMBoot volume.

 

There's no registry entries on that forum, by the way. I'm sure you'll let me know if I've missed the obvious.

 

I'm already injecting into WinRE using WIMLIB, so we're almost 100%.



#159 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 14 August 2014 - 10:35 AM

There's no registry entries on that forum, by the way. I'm sure you'll let me know if I've missed the obvious.

Well, yes, I would define it as "obvious", look on the post right after the one where the files are listed, by the same poster alacran, that contains a - again "tentative" - list of Registry entries (inside "spoilers").

I.e. this one lists files:

http://reboot.pro/to...mboot/?p=183981

and this one lists found Registry entries:

http://reboot.pro/to...mboot/?p=184017

 

but - as said - just a start point.

 

:duff:

Wonko



#160 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 15 August 2014 - 07:44 PM

OK, I got that part down.

 

Now, any thoughts on what might be necessary for wimgapi.dll to be updated to take it from PE 5.0 to PE 5.1?

 

I mean, I could just copy the DLL, but it might have some additional dependencies, of course...



#161 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 August 2014 - 07:05 AM

OK, I got that part down.

 

Now, any thoughts on what might be necessary for wimgapi.dll to be updated to take it from PE 5.0 to PE 5.1?

 

I mean, I could just copy the DLL, but it might have some additional dependencies, of course...

Run getwaiktools.

http://www.msfn.org/...-the-huge-isos/

 

Each version/folder should be the "complete" set of needed files.

 

Have a look here - reading between the lines - to verify versions:

http://www.msfn.org/...sions-compared/

 

But weren't you using the Wimlib instead of the MS files? :unsure:

 

:duff:

Wonko



#162 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 16 August 2014 - 07:59 AM

There's a little bit of problems with WIMLIB that we're working to resolve - I've sent Eric full dumps of the registry folders; because certain registry entries are magically disappearing after some restores using WIMLIB (but the same restores work with WIMGAPI). WIMLIB runs circles around WIMGAPI when creating images, and I'm confident Eric can resolve the issues during restore too.

 

I managed to solve the problem of upgrading the WIMGAPI too, using the links you provided. Still doing some more testing, but right now, all edge cases, as well as main use cases, appear to be covered 100%. WIMGAPI has never failed to date on any restore effort, the irony is that WIMGAPI is using WIM's created by WIMLIB itself :)

 

I'll be issuing a new updated build of ZIPmagic soon, with these (and other) enhancements. ZIPmagic itself is updated to handle RAR5 format files. It can also optionally nest all of its Explorer context menu entries under a single ZIPmagic heading now, and a bug with its 64 bit Outlook Add-In has been fixed (it failed to detect embedded attachments, but only in the 64 bit version, because MS folks had changed a function import from ordinal type to something else).

 

The only outstanding issue is the Surface system stall that I experienced for 30 minutes when using certain disk imaging tools, and that another user experienced for 2 minutes. He still hasn't provided the requested boot dump. I tried to create my own boot dump, but I started getting blue screen errors in some nv**.dll during my boot efforts immediately after activating the boot trace process. Go figure! At any rate this seems more and more like a red herring, because on out-of-the-box Surface systems, and those that haven't been mangled by disk imaging software, everything is working remarkably well out of the box:

 

- Initial compression without undo disk at any compression grade

- Re-compression with Undo Disk at any compression grade

- Automatic creation of the boot entry based on the WinRE image with the WoF patches and the wimgapi.dll updates

- As long as the user selects the boot entry, DoubleSpace automatically processes with settings chosen before reboot

- Temporary WinRE image and the boot entry are also automatically removed after processing

 

I'll be sure to drop a note when ZIPmagic 12.1 with all of the above fixes and enhancements is live.

 

It's time for thumbtack collection...seems like I won't be needing to bang my hand on this table no more :) It's taken some months and a lot of back and forth, but all project goals have been achieved:

 

- Single-click WIMBoot compression, with even better than Microsoft compression savings, and shorter processing time; without requiring external storage, command line finagling, or any kind of manual processing. Just click, sit back, relax, and enjoy :D


Edited by simonking, 16 August 2014 - 08:06 AM.


#163 milindsmart

milindsmart

    Frequent Member

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

Posted 16 August 2014 - 08:38 AM

Nice work @simonking ! I only read through now, your project is interesting. I will comment more when I get some ideas, but right now, I have a huge doubt, both to you and many others in reboot.pro :

 

Why are you all having so much trouble with UEFI? It's a robust system that is supposed to JUST work. I have executed windows boot like running a command line file : that's how flexible the shell is. So why is it so hard? What issues are you facing on UEFI? GPT already makes life so much better so that you aren't restricted in the number of partitions.

 

BTW, I wondered why you had to struggle to find the recovery image, instead of using reagentc /info ....?



#164 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 August 2014 - 09:07 AM

 

Why are you all having so much trouble with UEFI? It's a robust system that is supposed to JUST work. I have executed windows boot like running a command line file : that's how flexible the shell is. So why is it so hard? What issues are you facing on UEFI? GPT already makes life so much better so that you aren't restricted in the number of partitions.

 

Not that the limits in BIOS are much "strict".



3 primary partitions + 1 Extended one that can contain as many volumes as you want, and that can be made bootable as well (as if they were primary).



In real life (and with the due exception of some stupid setup by HP and other large OEMs on notebooks) it is rare to find a system where more than two partitions are used, with the large majority set to have just a single (nowadays senselessly large) partition.



So it is nice to have now all primary partition and - usually - have entries for 128 partitions, but it is not like it will change anything for the "average Joe".



Simonking will tell you how the Surface (1, 2 and I believe also 3 :unsure:) have only three or four partitions, as an example.



UEFI may be robust in itself (as a set of specifications), but the different way it has been implemented by everyone makes it - until things settle down and "converge" to an actual "standard" - less stable of the average BIOS one.



:duff:

Wonko



#165 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 16 August 2014 - 10:47 AM

Thanks milindsmart! In gratitude for the help I have received from this forum, I still have an ongoing license give-away - just PM me if you want to check out the official distribution with a licensed serial key. Please note that I welcome beta feedback with DoubleSpace, DriveSpace, Stacker, and the rest of the ZIPmagic suite as well.

 

The problems with the Surface...harrowing. As you know, the "latest and greatest thing" is always advertised as "it just works", but in the "real world", this claim is always proven to be false. In my case, I have experienced some really harrowing problems with my Surface's. I frankly do not know how they came about, my suspicion is that some disk imaging tools I used made some changes somewhere - who knows where - and this accounted for the problems. However, the problems have been of this nature:

 

1) If more than one boot entry is defined, a lengthy stall before boot.

2) If the single boot entry is defined and that is VHD boot, again a length stall before boot.

3) The same for WIMBoot.

 

A lengthy stall before boot has, in my case, been a 20-30 minute delay with the "Surface" logo shown on the machine - to the point that when this was initially happening, I was sure the machine had just crashed or frozen without indicator. One day randomly it finished the boot, which is when I discovered that the issue was not a lockup but a stall. If you wait long enough, the spinning boot indicator shows eventually.

 

Right now I am avoiding this problem by not using any third party tools to image my disks and to move my data. DoubleSpace has been, a remarkable cure in that sense. For instance, I migrated from my Surface Pro 2 to my Surface Pro 3 using DoubleSpace itself! Certainly this did not create any boot stalls and safely and reliably moved all of my data over. A never expected application of my disk doubling software, a pleasant surprise to be sure.

 

Unfortunately there seems to be nothing DoubleSpace can do when the problem has been pre-introduced to an operating environment through a disk imaging software or - who knows what. I figure this, because a customer using DoubleSpace reported a 2 minute boot delay. (S)he was lucky - 2 minutes is a heck lot better than 20 or 30 - but still, its a great inconvenience; especially when the device can boot instantly, even with DoubleSpace compression, under normal circumstances.

 

Because I did not even touch my 64 GB Surface Pro 3 with any disk imaging software, even though this system has a meager i3 processor, it still boots very fast, and there's no stall or delay before seeing the boot spinner.

 

Right now I do have my old Pro 2 lying around...I was able to cure its boot delay problem using Macrium Reflect (free edition) and a brand new image of a Surface Pro 2, obtained before even power-on. I find myself now in the fortunate position of having to re-create the problem there somehow, so I can finally obtain that boot trace suggested by Trip.

 

I cannot understate how unnerving this issue is. Case in point: I did try Trip's suggestion on the problematic Surface Pro 2, but it started blue-screening with an error in some DLL called nv***. And it took me about 5-10 boots to even get to that knowledge! Keep in mind too please, that each test cycle takes about half an hour. The machine would simply shut down after showing the blue screen for a few seconds (I am lucky I saw it at all, after 5-10 attempts). I thought the battery must be dead (it wasn't, I should have known better), there were other oddities too even - I even saw an amber light glow on the right side of my Pro 2 during some of the test cycles. Google'ing this resulted in a "return to technician" result; but the light is currently gone and after restoring the clean image, the boot problem is gone too!

 

So anyways, this is a really nasty issue - my only current consolation being that it is not caused by DoubleSpace, although of course if I could fix it, I want to figure out how - since it does affect DoubleSpace's use (the problem being unnoticed in a single-boot-menu setup, when VHD/WIMBoot is unused).

 

Oh, last but not least - part of my symptoms were an actual 30 second - 1 minute delay before even getting to the boot menu. The customer did not report that and I have not been able to reproduce that so far either...so we'll see what happens.

 

I have been completely unable to reproduce any of these results inside a VM environment...not knowing what actually caused them in the first place, that makes sense.

 

One possibly relevant bit of information is; when I run bcdedit on my Pro 3 or a VM, it returns instantly. When I run bcdedit on my Pro 2, it returns after a 5-10 second delay. This bcdedit run could be just running the program without any parameters, or running it to add a boot menu entry, or delete one, or update one, what have you. Regardless, there's always been this lengthy delay. Not only do I have no clue why, this has always been the case with the entire Pro 2 line as far as I know. I do not know if somehow all Pro 2's I got my hands on had problems, or what have you. And whether this issue and the main issue I have noticed are related at all...


Edited by simonking, 16 August 2014 - 10:53 AM.


#166 milindsmart

milindsmart

    Frequent Member

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

Posted 16 August 2014 - 12:00 PM

Ah that is pretty nasty! I don't think though it's specific to UEFI : It's just an evil quirk of that particular hardware.

 

How about taking a sector by sector backup (dd) of the protective MBR, ESP, and the windows partition, before and after the problem occurs? I know it's not easy, but I guess that's the only way to get to the bottom of it.

 

BTW, to clarify, DoubleSpace is software to convert a given Windows installation to WIMBoot-style... right?



#167 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 16 August 2014 - 12:05 PM

Yep, that's right. It'll take any Windows 8.1 Update 1 installation, and WIMBoot it for you. Without needing anything extra - just the software. On average, it does double your disk storage. Really incredible! Eric has done a wonderful job implementing WIMLIB...I love his extra compression settings. Truly phenomenal.

 

Some tips I've learned working with WIMBoot over time (I use it on my development PC - the 64 GB Pro Surface line - so it is a case of "necessity is the mother of invention"):

 

- Move the files you update frequently (your email data file, etc.) to another partition or external USB before processing

- Delete all files you may potentially delete before processing

- After processing, add these files back in, and run DriveSpace (DoubleSpace's NTFS based cousin) to compress them too

 

WIMBoot will not re-compress files on-the-fly, unlike NTFS compression. It also will not recover space from deleted files, when those files were included in your base image. That's why the above tips are helpful.

 

I recompress my system about once a week on average to pick up the slack from the last compression round...



#168 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 16 August 2014 - 02:52 PM

It's done. 12.1 is live at the main site (www.zipmagic.co). Please enjoy all the latest and greatest fixes and enhancements :)



#169 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 August 2014 - 06:18 PM

@Simonking

Good :), now could you share with us, possibly on the mentioned thread:

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

the following:

  1. the list of files for WOF booting you added to the WinRE
  2. the list of the exact Registry entries and their contents
  3. the exact way you added this (how you serviced the WIM, etc.)

:unsure:

 

:duff:

Wonko



#170 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 17 August 2014 - 07:31 AM

Glad to:

 

1) The exact same list of files you linked me to.

2) Same as #1.

3) I used WIMLIB to service the WIM. I'm sure you could also service it with DISM, etc.



#171 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 17 August 2014 - 07:54 AM

BTW on the UEFI issue. I got my hands on an HP Envy laptop yesterday, with an AMD CPU. Nice, hadn't seen one of those in a while. So anyways, DoubleSpace ran beautifully on it. No boot stalls before, during, or after the entire WIMBoot process.

 

WinRE location also went through successfully, with all on-the-fly modifications equally successful.

 

The HP Envy had a mechanical hard drive, so I also got to try that scenario out. From what I can tell, it's not really much slower (or faster) than it was before. So WIMBoot seems equally applicable to mechanical disks, a finding that has also been corroborated elsewhere on this forum. I'm sure that'll be quite a relief to mechanical drive users.



#172 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 August 2014 - 10:36 AM

Good :), though  I asked you if you could provide the EXACT list of files, of Registry keys and the EXACT command (besides the chosen tool) with which you serviced the WIM.

 

Since you succeeded at it, f you provide the COMPLETE, EXACT, FULL sequence of steps you did successfully, THEN it will be easily repeatable (and other members willing to do the same won't need to put together the pieces of the puzzle, finding them all together in one place).

 

:duff:

Wonko



#173 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 17 August 2014 - 11:12 AM

I can't give you a command - I didn't use the command line tool at all. I am directly calling WIMLIB from DoubleSpace through its API/DLL. Again, the exact list of files and registry keys are in the links that you provided. No less, no more :)

 

Of course, DoubleSpace remains available to everyone who doesn't want to reinvent the wheel.

 

It is currently super stable - using the best of WIMLIB and WIMGAPI - and doing many things that you couldn't just do from the command line using either API/framework/toolset. You'd have to be a programmer and write your own code to do what DoubleSpace is doing (processing disks on the fly without needing external storage). You can't do that from the command line or with any currently existing command line tool.



#174 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 17 August 2014 - 01:57 PM

I can't give you a command - I didn't use the command line tool at all. I am directly calling WIMLIB from DoubleSpace through its API/DLL. Again, the exact list of files and registry keys are in the links that you provided. No less, no more :)

 

Of course, DoubleSpace remains available to everyone who doesn't want to reinvent the wheel.

 

It is currently super stable - using the best of WIMLIB and WIMGAPI - and doing many things that you couldn't just do from the command line using either API/framework/toolset. You'd have to be a programmer and write your own code to do what DoubleSpace is doing (processing disks on the fly without needing external storage). You can't do that from the command line or with any currently existing command line tool.

Good :), then (though I doubt that Sinchronicity has included in Wimlib functionalities not accessible through command line :dubbio:) - alternatively - could you - as a sign of appreciation for the help received from the reboot.pro community - make available a compiled program that ONLY updates the WinRE.wim containing a PE 5.0 to a PE 5.1 or however to a PE 5.0 capable of using the WOF driver (by "snatching" the files from an existing suitable install of Windows 8.1)?

 

:duff:

Wonko



#175 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 17 August 2014 - 02:16 PM

 

though I doubt that Sinchronicity has included in Wimlib functionalities not accessible through command line :dubbio:

 

 

Not much, primarily extra progress messages that frontends other than wimlib-imagex can take advantage of.  For "on the fly compression", I added WIMLIB_PROGRESS_MSG_DONE_WITH_FILE, which wimlib-imagex does not use, but Simon's code uses to delete a file as soon as wimlib has written its data to the WIM file.  (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".)

 

With regards to compression modes, they can all be accessed from wimlib-imagex using the --compress and --chunk-size options.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users