248 replies to this topic

[cdob]

I had assigned the drive letter R: to the recovery partition previously with diskpart.

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=R:
description             Windows Boot Manager

Windows Boot Manager | Windows failed to start...
Status: 0xc000000f
A required device isn't connected or can't be accessed.

Are Windows Boot files (e.g. \boot\bcd) stored at partition r: ?

[simonking]

Yes. This is a clean install of Windows 8.1 into VMware (BIOS mode), and then Update 1 applied manually; so results should be instantly reproducible in any VMware environment:

 

R:\Boot>attrib

A  SH        R:\Boot\BCD

A  SH        R:\Boot\BCD.LOG

A  SH        R:\Boot\BCD.LOG1

A  SH        R:\Boot\BCD.LOG2

A  SH        R:\Boot\BOOTSTAT.DAT

A            R:\Boot\memtest.exe

[misty]

I have no intention of getting into a flaming war with anyone - the following comments do not warrant a response - I'm just exercising my right to express an opinion - particularly as I have attempted to contribute to this thread.

For the record, I'm happy to let Wonko speak on my behalf in my absence - whilst I have jokingly referred to him as cracking the whip in the past, he has motivated me into producing what I consider to be my best work. You may not always get a yes or no answer from him, however the journey is interesting and I've learnt far more from him encouraging me to find my own answers and experiment than I ever would have from a more direct 'this is how you do it' answer.

Also consider that Wonko's prompts for more information, whilst maybe appearing to you at times to be bordering on harassment, have teased from you some of the information required by the rest of us to make our suggestions. I suspect that if he hadn't responded this thread would have sunk into obscurity.

End of

Now back to the discussion.

Is partition r: your active primary partition containing bootmgr in addition to the BCD store?

Also, did your batch run without any errors?

I would consider creating a new BCD store manually (using bcdedit) with just the options required for booting WinRE - in fact add a duplicate menu entry for the same WinRE so that you actually see a boot menu.

Misty

[simonking]

R: is indeed the active primary partition.

 

The batch ran without errors.

 

bootmgr is indeed located at r:\.

 

None of these results merit any shock; they would be instantly reproducible running VMware on a generic Windows 8.1 install (BIOS mode).

[misty]

Your freelancer project mentions the following -
 

1) You can assume the latest version of WAIK will be installed.

Why? This is an awful amount of bloat to download and install and is probably not required - in my opinion.

I'm still not clear on your goals. Can you please explain what you are trying to do - step by step would be useful. E.g.

• Create WinPE 5.1 with a custom application (how will it be launched? Options include via command line, via a GUI shell, via winpeshl.ini)
• Add an entry for the customised WinPE to the boot menu
• Boot WinPE and compress the drive using a custom application
• etc

If you are planning to compress the drive contents after installing the WAIK as a requirement, consider that you have added several gigabytes of (possibly unnecessary) files. Not a selling point if drive space is an issue. This is an assumption on my part. Clarifying what you want to do will reduce the number of assumption we (the people that are trying to help you - for free) need to make.

As all of the files (boot files and winpe.wim) are on the same volume, try using the following precompiled BCD store - it only contains an entry for winpe.wim (well two entries if I'm honest - to force the display of a boot menu). This store uses the boot device and the paths you specified in your own batch. The batch I used to compile the store is included in the attached .zip file.

Regards,

Misty

 BCD.zip   2.43KB   2 downloads

[simonking]

You folks are right about MS's licensing policy change on PE, it appears they do not license it to ISVs anymore. So the only legal way to produce PE would be through having a copy of WAIK installed - we can optimize the installation process later, I just need something that works right now, so I can make progress on the project. The app is ready, this is the only outstanding issue:

 

You cannot create a WIM of a system that is running live, so you have to be able to run another copy of Windows, which it makes sense for it to be PE, so you can process the actual main Windows installation offline. I have run countless tests using USB removable media, and it all works fine. The goal is to also be able to eliminate the external USB requirement - if only to make things easier for less sophisticated users.

 

Your step by step goals are right on the money; the goal is to have a PE instance that can be launched "programmatically" - by editing the BCD (using bcdedit, if necessary - as the APIs are very complex) on-the-fly, making the PE instance the default choice, rebooting directly into PE; where my DoubleSpace app runs, and then makes the main Windows instance default and reboots again.

 

I'll check the ZIP you provided and let you know what I find.

 

PS: Configuring a custom app to run on PE is trivial, so I haven't particularly dwelled on that requirement here.

Edited by simonking, 08 July 2014 - 08:16 PM.

[simonking]

All commands succeeded when I ran your batch. After restarting Windows, however, I booted straight back into Windows itself. Not sure why it did not boot into PE/RE. Would manually replacing the BCD file make any difference?

[misty]

All commands succeeded when I ran your batch. After restarting Windows, however, I booted straight back into Windows itself. Not sure why it did not boot into PE/RE. Would manually replacing the BCD file make any difference?

That depends on whether you deleted your existing BCD store and then used my batch to create a new R:\boot\BCD. It's a trivial matter to replace the BCD store with the one I uploaded so I'd suggest a quick test with it.
 
Noticed this in a previous post of yours -

.....@Wonko: More bad news for the WinRE reuse idea comes from, maybe you guessed it, the Surface Pro front. I assigned partition letter R to my recovery partition using diskpart, and here's what I get on the command line:

C:\Users\c>chkdsk r:
The type of the file system is RAW.
CHKDSK is not available for RAW drives.

I don't have access to anything as modern as a Surface Pro so this is just speculation. It's possible that the recovery partition uses a none FAT/NTFS partition ID code - in which case it might appear to be RAW. It's worth checking the partition code using diskpart to rule this out - select the relevant partition and run the detail part command, then check the Type:

Regards,

Misty

[simonking]

Here's the command output:

 

DISKPART> detail part

 

Partition 1

Type    : de94bba4-06d1-4d40-a16a-bfd50179d6ac

Hidden  : Yes

Required: Yes

Attrib  : 0X8000000000000001

Offset in Bytes: 1048576

 

  Volume ###  Ltr  Label        Fs     Type        Size     Status     Info

  ----------  ---  -----------  -----  ----------  -------  ---------  --------

* Volume 3                      RAW    Partition    340 MB  Healthy    Hidden

 

Assuming this is an issue that could be programmatically reversed, it might rescue Wonko's recycling WinRE idea, a far better alternative to having to download components for WinPE.

 

Replacing the BCD failed, because "the file is in use by the System". I did remove the hidden and system file attributes. If there's a way to unlock the file, of course, I'd love to hear about it.

[misty]

Replacing the BCD failed, because "the file is in use by the System". I did remove the hidden and system file attributes. If there's a way to unlock the file, of course, I'd love to hear about it.

I usually boot into WinPE and just delete it. Never had any problems with this approach, but then I usually boot WinPE via Grub4dos and this may result in the BCD not being kept open in the same way as when directly loading bootmgr via the VBR code in the active primary partition.

Just out of curiosity - are you booting your full Windows 8.1 OS in the VM and trying to delete the BCD store from the running Windows?

Try booting WinPE from a USB stick if your VM supports this option - your BCD store on volume R: will not then be locked.

[simonking]

No, I'm using a generic install of 8.1 with U1 under VMware.

 

I've tried booting PE from a USB stick with VMware, but been unsuccessful so far.

 

Even though I attach the USB to the guest before even the BIOS has shown, there is just never an option to boot from USB in the BIOS.

[simonking]

Correction to my earlier statement - Assuming this is an issue that could be programmatically reversed, it might rescue Wonko's recycling WinRE idea, a far better alternative to having to download components for WinPE. - we'd still need to find out whether this WinRE is updated when installing Windows 8.1 Update 1 to include the WoF driver. I unfortunately still need to rely on WIMGAPI for applying the WIMs that I create, as such this limitation (as I've already informed Eric, developer of WIMLIB, I get the best results when using WIMGAPI to apply the image - using WIMLIB has resulted in the very odd case of an indefinitely spinning boot spinner during Windows boot, apparently randomly, on my problematic Surface Pro's).

[misty]

Can you mount your virtual disk and delete and replace \boot\BCD that way?

[simonking]

Not sure how to do that with VMware VMDKs that are snapshotted, honestly.

 

Additionally, it would be better if the approach can work with what's already there, as that would serve the ultimate goal of the project.

 

Right now we're still some ways off from even adding WinRE to the boot menu, based off of the existing WinRE image that's on the rescue partition.

 

On that note, any thoughts on the partition type feedback?

[misty]

Additionally, it would be better if the approach can work with what's already there, as that would serve the ultimate goal of the project.

I agree - consider my suggestions trouble shooting! I honestly don't know why the batch you used yourself failed - hence this approach.

[simonking]

I've got no clue myself

 

However, again, reproducing this would not be any mystery - just install 8.1 in VMware, and bingo!

Edited by simonking, 08 July 2014 - 11:58 PM.

[misty]

@simonking
OK, another suggestion - don't know why I didn't suggest this last night. How about running WinPE from an .ISO file. I'd suggest a simple to use project such as erwan.l's QuickPE - or my very own MistyPE (excuse the shameless plug). Alternatively you could even use your Windows installation media and drop into a command prompt - you only need to delete the existing BCD store and replace it with a new one. The one I precompiled does not have an entry for Windows 8 - just WinPE. I still think it might help with trouble shooting.

I don't have VMWare Workstation installed - but do have a copy of VMWare Player floating around somewhere. Time permitting I'll try installing the Windows 8.1 Update 1 Enterprise Evaluation I have access to. It will be interesting to check how the installation works on an unpartitioned disk - something I've not done since I last installed Windows 2000 years ago.

Misty

[misty]

@simonking
The batch file you posted here specifies the wim file (with path) as - \recovery\windowsre\winpe.wim.

Have you added this wim file yourself? Or changed the name of winre.wim? Having completed the Windows 8.1 Update 1 installation in VM ware player the default file/path on my system is - \Recovery\WindowsRE\Winre.wim. Note the name of the .wim file - Winre.wim.

Your issue may be due to a simple typo error.

Regards,

Misty

EDIT - just checked and an incorrect file name for the wim file will produce the...

Status: 0xc000000f
Info: A required device isn't connected or can't be accessed.

...error you reported.

[misty]

@simonking
Google reveals that the partition type ID you reported for the Surface Pro (Type: de94bba4-06d1-4d40-a16a-bfd50179d6ac) is the standard GUID for a Recovery/utility partition. I do not have access to a UEFI system and cannot check the default Recovery Partition file system type myself - it's entirely possible based on your own reports of the problems with your device that your recovery partition is simply corrupted - possibly by your own experiments.

I'd suggest that you install Windows 8.1 to a RAW disk in a VM in UEFI mode - VMWare supports this - simply add the following (poorly documented) code to your .vmx file before installing Windows -

firmware="efi"

You are then free to experiment yourself.

Regards,

Misty

[misty]

Possibly offtopic thoughts/suggestions/observations.

You appear to be adamant that WinPE 5.1 is required. Updating WinPE 5.0 to WinPE 5.1 is a tedious and time consuming process. The MS instructions that cdob linked to in a previous post (http://technet.micro...y/dn613859.aspx) specifies the following steps -

• Install the ADK
• Download a number of updates
• Mount WinPE
• Use DISM (from ADK) to apply the updates to the mounted WinPE
• Unmount using the /commit switch

That's a lot of steps for a non-technical person to complete - and a lot of steps to script if you want to program this for the non-technical person.

Is the ADK actually required? It might be possible to do the following -

• Use wimlib to extract the contents of WinPE 5.0
• Download a number of updates
• Use DISM (native to Windows 7/8/8.1) to apply the updates to the extracted WinPE
• Use wimlib to create a new bootable wim file from the extracted and updated WinPE

The only issue will be whether the DISM version that ships with the OS works - if the ADK DISM version is required then at least part of the ADK is required - but definitely not all of it! BTW, using wimlib to extract WinPE 5.0 and then repacking it after the updates definitly works - I used the ADK DISM to apply the updates though.

If WinRE.wim is updated with the wof driver when updating Windows 8/8.1 to 8.1 update 1 then none of this needs to be done - this is something you will need to check yourself. Easiest way to test this is to boot to winre - drop into a command line - check for the existence of the wof driver. If this is the case then it's highly likey that a complete and updated Winre.wim is hidden in one of the updates.

Alternatively, consider that wimlib and WinPE 4.0/5.0 might work - you have mentioned that it doesn't work on your Surface Pro, however this device is in my opinion unreliable - due to the other issues reported it's quiet possible the OS is corrupt.

Also consider that the issue of wimlib not working may be due to you not correctly following instructions. I'd suggest that you try again in a VM.

Regards,

Misty

[Wonko the Sane]

I'd suggest that you install Windows 8.1 to a RAW disk in a VM in UEFI mode ...

 

... You are then free to experiment yourself.

 

 

 

Watch out , this is dangerously similar to the suggestions given in posts #2 and #4 ...

 

Such suggestions - just for the record - may be considered as "lectures" (not gracefully accepted) and that were excluded as "I cannot start from scratch...let's just take this as a given." (but being later used as the base for the frelancer requests as "We will use clean virtual machines for testing." ) .

Same goes about hinting that instructions may not have been correctly reproduced.

 

Wonko

[simonking]

Wonko, I've taken your advice and reported your latest post for harassment.

Edited by simonking, 09 July 2014 - 12:09 PM.

[simonking]

Misty, you are a life saver! I cannot believe that a simple typo like this would derail all of us for so long. Trying again now

[simonking]

Misty, I have two Surface Pro's - and on one of them, indeed, the R: partition can be accessed properly.

 

I have no idea what might have corrupted my recovery partition on my current production machine - what is most worrisome is that, I recently transferred to this machine from the other Surface Pro, and used imaging tools as part of the process.

 

Tied in to my earlier hunches documented here and on other forums, I seriously suspect that some of these imaging tools are at least partly to blame for the spontaneous corruption of my boot menu (like a downgrade into text menu) and extensive VHD boot delays that appear inexplicable otherwise. However, then, other consumers might be hit by the same problem.

 

All the same, if WinRE is indeed updated to PE 5.1, I suppose the best thing to do would be to just use it, or ask the consumer to bring his own PE 5.1 stick. Indeed, building a PE 5.1 stick is intensely laborious; even when done programmatically, it would require gigs of downloads.

 

Part of me just wants to distribute my own VHD alongside my software, hoping that Microsoft would understand

 

I also need to emphasize that I cannot discount any of the Surface Pro corruptions on any account; because these will be a large portion of my hoped-for consumer base. Simply the fact that Surface Pro's can only run Windows 8.x itself probably makes them a very, very large portion of the consumer base

 

I wonder if it might be possible to install Windows 7 via VHD boot to Surface Pro's...

Edited by simonking, 09 July 2014 - 11:39 AM.

[simonking]

Success! With the P replaced by R, I was able to boot in, at least inside VMware, to the recovery partition.

I'm going to try this on my live Surface now too, the one with the seemingly corrupted recovery partition. [Edit: I decided I am not brave enough to attempt this on my live Surface, given the major hurdles remaining below still]

 

Next hurdle: WinRE boots into some more ugly square looking tiles with options to recover the system. It is possible to drop down to the command line, but one needs to enter the password of the current admin account on the primary OS, after navigating through two tile based menus. So it looks like there's some work still to be done for:

 

1) Auto-logon and auto-run-app using WinRE.

 

And the bigger bit of bad news: WinRE is not updated to PE 5.1.

 

2) Need to figure a way to update WinRE to PE 5.1.

 

I suppose, hypothetically, it might still be possible to achieve objectives this way (using DISM to update the WinRE image, etc.) but the unknowns are growing for sure.

 

Here's the error output from both DoubleSpace and Erwan's command line analyzer:

 

---------------------------

ZIPmagic DoubleSpace

---------------------------

Unable to copy X:\Windows\system32\WimBootCompress.ini to D:\config.ini

 

Cause: The system cannot find the file specified

---------------------------

OK   

---------------------------

 

D:\wimboot-analyze>wimboot-analyze-x64.exe d:

--------------------------------------------------------------------------------

 

Analyzing "D:\wimboot-analyze"

WARNING: "D:\wimboot-analyze": The Windows Overlay File System Filter is not run

ning.

         It will be impossible to determine which files (if any) are

         externally backed (e.g. are WIMBoot pointer files)!

 

--------------------------------------------------------------------------------

 

Directory count:              1

Nondirectory count:           7

Reparse point count:          0

 

Total file contents nominal size:       127,356 bytes

Total file contents allocated size:     135,872 bytes

Edited by simonking, 09 July 2014 - 11:55 AM.