248 replies to this topic

[milindsmart]

[...]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

Well I had said it quite a while back

[Wonko the Sane]

Well I had said it quite a while back

To be fair, long before that some 10 posts starting from here:

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

revolve around:

1. where the WinRE.wim is placed in the case of "standard", "OEM" or "end user" setup
2. how to find if a WinRE environment/boot option exists and where the related WinRE.wim actually is 

 

All in all I would store the reported issue among the "not surprising" ones.

 

Wonko

[Tripredacus]

As an aside, I forgot about this until now... But does Simonking's software account for those situations where the PC has 2 recovery partitions?

http://www.msfn.org/...very-partition/

[simonking]

It would grab the WinRE instance from the first partition it finds. Which shouldn't be a problem, because even the 8.1.1 WinRE is still identical to the 8.1.0 (and possibly 8.0) WinRE. Also, there's no telling which partition gets enumerated first by the partition enumeration API. So it might be the first, or the second, in the order of creation.

[simonking]

Folks, do we have any updates on trying to get the WoF driver running on older Windows versions?

 

From my understanding of the current situation, older version Windows bootloaders work on Windows 8.1.1 successfully in booting Windows, even with WIMBoot - but getting the WoF driver working is not happening - is that correct?

[milindsmart]

Any updates on that mysterious slow startup thing that you encountered after imaging the Surface? I used to have a similar problem that seemed to have gone away, but now it's back... a VERY long startup, with SUPER slow dots moving... like one frame in 2 seconds... happens when I hibernate/hiberboot. Familiar?

[simonking]

That's not what I saw. For me, it took for ever for the dots to start moving. Once they did, the boot was at regular speed - no stall whatsoever during the dot rotational phase. However, it took up to 30 minutes to get there.

 

I have not focused on reproducing that issue, fortunately it does not manifest on my Pro 3 Surface. It manifested on my Pro 2 Surface and, as best as I was able to determine, due to my use of Paragon disk imaging tools which changed the PBR or MBR or something else known. I even asked Erwan's help for this and he helped me dump the PBR/MBR's, which showed that Paragon was applying the Windows 7 PBR and/or MBR after imaging. Most probably this was the cause, by restoring the correct PBR/MBR using Erwan's tool did not help (assuming CloneDisk was working).

 

Fortunately during the transition from Pro 2 to Pro 3 I was able to use DoubleSpace itself for the migration; simply booting off a Windows PE 5.1 USB with the proper WIM file was sufficient to migrate the system - without even having to use any disk imaging tools at all. This is a very nice side-effect of DoubleSpace (try double-clicking the program icon in the window for the hidden options) which saved me on the Pro 3's.

[simonking]

The menace is back! After helping a migration from a Pro 2 to a Pro 3 using Macrium Reflect Free Edition, and then DoubleSpace'ing the drive, the boot is taking inordinately long again. Not as long as 20-30 minutes, but certainly much longer than how much a direct DoubleSpace/WIM based migration would take to boot: ZERO delay.

 

While I still have access to this precious jewel of a system, may I tax everyone's patience one last time (as I know this information has been requested and supplied before), as to what I should do for tracing this boot process in detail, and isolating the part of it that is actually causing the hangup?

 

I appreciate all help very much!!!

 

All your slow boot are belong to us!!!

[Wonko the Sane]

 
All your slow boot are belong to us!!!

Actually,  they belong to MagicAndre1981!
 
Here:
http://www.msfn.org/...ernates-slowly/
 

Wonko

[simonking]

OK, so this is my problematic trace result:

 

postBootRequiredIdleTime="10000" osLoaderDuration="443304"

 

How could the osLoaderDuration take so long? Any way to diagnose what's happening then?

[Wonko the Sane]

OK, so this is my problematic trace result:

 

postBootRequiredIdleTime="10000" osLoaderDuration="443304"

 

How could the osLoaderDuration take so long? Any way to diagnose what's happening then?

Post a full trace (not a single line taken out of context) on the mentioned post and see if MagicAndre has some ideas on the tests to be done.

 

Personally I would recreate a \boot\BCD from scratch, first thing.

 

Wonko

[simonking]

You're missing the point, osLoaderDuration appears to be an atomic item with no further details available. _*That*_ is the problem.

[simonking]

milindsmart, here's the output from reagentc /info:

 

http://www.zipmagic....?f=1&t=52&p=109

 

Does this provide us with any clues as to what to try next? Check the full screenshot above, looks like the customer may have nuked everything actually.

[Wonko the Sane]

You're missing the point, osLoaderDuration appears to be an atomic item with no further details available. _*That*_ is the problem.

I am most probably missing the point , but still you decided to NOT follow the "standard" set by MagicAndre (which is the only one that I know that may read and understand a trace and the one that actually "invented" this approach to troubleshoot this kind of issues).
So, you are also missing it .
 
If MagicAndre asks for a full trace, unless you know more than him on the specific topic, you should provide him with a full trace, then do whatever tests he may suggest.
Otherwise, logically, you would have been capable of solving the issue by yourself.
 
More or less we are within the "common sense advice" points #f.:
http://reboot.pro/to...82-board-rules/

About:

Does this provide us with any clues as to what to try next? Check the full screenshot above, looks like the customer may have nuked everything actually.

The OP seemingly admitted having deleted the WinRE.wim:
http://www.zipmagic....t=52&p=109#p107
so IMHO not really a "surprising" output of reagentc /info.
Until he procures a copy of WinRE.wim (from a backup, an install DVD or a downloaded .iso) there is nothing that can be tried next.
Once it has it, it should be just a matter of running reagentc setting the WinRE.wim location properly:
http://technet.micro...y/hh825204.aspx
 
 

Wonko

[simonking]

I've already asked the man who owns all our boot speed what to do about the boot trace.

 

In the other case, yes he has admitted to deleting everything

 

For the record, even on my tablet, I get a very similar output:

 

C:\Windows\system32>reagentc /info
Windows Recovery Environment (Windows RE) and system reset configuration
Information:

    Windows RE status:         Disabled
    Windows RE location:
    Boot Configuration Data (BCD) identifier: f8db333a-6f15-11e3-9c00-281878d8fc
61
    Recovery image location:
    Recovery image index:      1
    Custom image location:
    Custom image index:        0

REAGENTC.EXE: Operation Successful.

 

However in my scenario, there is a recovery image index displayed (note that there's no location).

 

In this case my tool (the EXE posted here, as well as DoubleSpace, of course) still works correctly

 

I am suspicious there might still be a thing or two that might be done with this customer too.

 

Going to try and create a VM with a manual install process, to see if I can nail down a copy of WinRE there.

 

As you can see milindsmart, the output of reagentc is not very reliable...non-kevlaric

[Wonko the Sane]

AFAICU the "disabled" status is not the intended status.

Do you mean that your "brand new" and "before fiddling" Surface (2 or 3) has that set as "disabled" or that you have it disabled after applying the doublespace/wimboot/whatever?

 

I mean, you should check how it is initially (it should be "Enabled" and working/bootable) and see if you can re-enable it (and test it boots) on your machines after the tool has been run.

 

Which brings you  - again - here:

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

 

Or - alternatively - stop claiming a supposed kevlaric status of the thingy and call it plainly experimental or more simply half-@§§ed

 

The WinRE environment is more or less the ONLY way (without an external booting media such as a CD/DVD or USB device with a PE) to recover from a number of booting issues that a Windows 8/8.1 user may have and it is IMNSHO vital that this possible "way out" is working.

 

Wonko

[simonking]

Talk about your own @$$, Wonko the Insane, lest you sound like one.

 

Like how did you sound like one here?

 

By getting confused between the 5 gig recovery image, and the header partition containing a micro WinRE instance that's only 300 megs tops.

 

You're just plain offensive sometimes, dude. Go take a break and visit nature or something.

[Wonko the Sane]

I don't get it.

 

Set aside your offended sensibility (or your being exceedingly touchy), the WinRE should be (at least according to MS) an option (not necessarily connected  from the recovery image/partition feature) available in the \boot\BCD (actually defaulting to it) in case of booting issues.

 

It is the Recovery Environment, and as said earlier it is now mandatory for OEM's.

 

It should be normally enabled and working/bootable:

http://technet.micro...y/hh825173.aspx

http://technet.micro...y/hh824837.aspx

 

Reagentc is the tool to verify that the environment is available and enabled, but one should anyway test it is actually booting correctly.

 

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

 

Windows 8
Press WinKey+I and click the Power icon. Hold down Shift and click Restart. Click Troubleshooting and then Advanced options to bring up the repair options.

 

 

On any original OEM install the above should be able to start to the WIndows Recovery Environment, and the same should happen on a "brand new" Surface.

 

Wonko

[milindsmart]

About the slow boot : I don't understand why you can't at least open the .etl file in Windows performance analyser and check out why it's so slow, instead of fretting with one goddamn unhelpful line in an XML file!

Further, if the machine in question is mostly clean and you think it doesn't contain customer private data (directory paths, startup programs) just upload it!

About WinRE :

run reagentc /enable and then see what happens when you type reagentc /info

[simonking]

You do get that the boot loader is recorded as an atomic operation and none of the extra info in the XML or wherever else is relevant or slow, right?

[milindsmart]

I'm not sure the .etl would include no additional detail. And he's quite the man of few words, he really hasn't confirmed or denied your assertion about it being an atomic measurement, unless you talked to him through PM.

So did you try out my above suggestion?

[simonking]

Feels to me like he's confirmed, of sorts. I did load the ETL. There's lots of interesting graphs and things, but nowhere can my huge delay be seen. I do think this lends further credence to the atomicity.

 

On a more positive note, I've updated my WinRE tool here:

 

http://www.zipmagic....magicwinre.7zip

 

It now detects WinRE found in additional locations; namely non-hidden logical volumes, such as the C: drive you end up with when you manually create a single partition spanning your entire disk and install there.

 

DoubleSpace also updated, of course. Please enjoy

[milindsmart]

Oh so you were right then.

I still want to know whether you tried reagentc /enable on your Surface when it is showing status as disabled.

[simonking]

No, I didn't try that. I don't need the reagentc behavior at any time for my own use.

[milindsmart]

Well I wanted you to try it out. It enables smoothly and shows the path of WinRE.wim. Either it remembers elsewhere, or it searches once the command is given. Anyway that's one potential solution to "WinRE.wim not found" errors. That's all.