BCDBoot Failed with Return Code 193

[ngrl-librarian]

Hi,

We've successfully used your version of Steadier State for ~15 Windows 10 PCs so far, all on one of the earlier versions.

Currently, we're trying to install the newer version on some new laptops and we've had two that worked fine, but on this one we've run into an error. It is successful up to the part where it plans to copy boot files from image.vhd. At that point, we receive 'Failure when attempting to copy boot files' and then 'ERROR: BCDBoot failed with return code 193'.

I've tried recreating the WINPE USB, disconnecting the external drive and restarting, and using bcdboot after it exited the Steadier State setup. In all cases, it brings up the same error. Any thoughts?

Sorry if this isn't the right way to do this.

[unixabg]

Greetings, Let us see if we can move you past the error. First can you confirm you are using the latest git master of https://github.com/7heMC/SteadierState?

I am going to assume yes above. Now since it worked initially for two units then stopped, I am suspect of something on the target drive that SteadierState does not like or can not handle. So if it were me, ymmv, two things:

1. You could just move on to the next unit you want to convert to the latest SteadierState, if all goes without issue, then this would suggest something with the drive on the machine with error.
2. I would try zero filling the drive for just a short bit, just long enough to drop partition table and boot sector (I use a Linux live key and dd command for this) and then repartition and format ntfs with whatever tool you want. As I recall you also have to set the boot flag on the drive. That step should eliminate any target drive issues, assuming the drive is not defective.

Please report back so we can assist further if need be.

[ngrl-librarian]

I've tried the newest version on a different PC successfully. I used the image.vhd from the other PC (same hardware/software) and that seems to have worked.

See below for notes on other issues I ran into as I tried test the newest version on our PCs. Fortunately, I figured those out.

After having run firstrun.cmd on the new version, I went to test it and it is not automatically rolling back. Right now, any changes I make are sticking, even though I don't have any directives in the file. When restarting, it doesn't show the WINPE interface like it normally does for a minute or so as it changes the snapshots. Is there something I'm missing? Previously, you simply added an automerge.txt into the physical drive and it merged and deleted the automerge file if you wanted to make a change, and it restored if that file didn't exist.

EDIT: Apparently, even though I am in whatever the default mode is (presumably roll back mode), to complete the automerge.txt directive, I have to run C:\srs\bcddefault.cmd. At that point, it will properly automerge--however, I have to run manually C:\srs\bcddefault.cmd every time I restart for it to roll back. I'm clearly missing something or somehow messed something up.

EDIT 2: Turns out, the bcddefault command task is scheduled to only work if a device is plugged into the AC power. If I plug the laptop in, it works as expected. Might be a good thing to note in the instructions.

Thanks for your help!

[unixabg]

Greetings,

Very glad you got all working. As for the "bcddefault command task is scheduled to only work if a device is plugged into the AC power" you are correct. I spent several hours at one point when I was developing with notebooks on some aspects of the project when I was puzzled about the behavior (notebooks unplugged) and discovered what was actually happening. I agree we need to document this, perhaps in a FYI section in the README.md file. Would that have helped you find this quickly?

fwiw: As I recall I think you can override that behavior but it was not something I needed when I was writing adjustments for my deployment model.

Again glad you are going and I would ask that we leave this issue open until we have finalized where to put the notes.

[ngrl-librarian]

I was able to override the feature pretty easily once I figured out that it was in fact the problem on that device by editing the task's conditions and unchecking the box that set it to AC only. I may put it back on temporarily in some instances because it could be super useful when doing things like big updates that might require lots of restarts.

An FAQ section or a troubleshooting section would be helpful. There are several places in the WinPE environment where it directs you to check the logs, without necessarily saying where the logs are, and if you're accidental IT like I am, the logs may or may not be very helpful. I would've looked for it in the ReadMe or some kind of help area.

I've found that for most troubleshooting, I have to open up the cmd files and read what's there to figure out what might be problematic (like figuring out why bcddefault wouldn't run). If there's an error code like 193, there's no real way to find help for that error short of googling it in general. I'm sure that someone well versed in programming would either know it already or know where to start.

I have step-by-step instructions (with images) that I created for the last round of devices to make life easier for my assistant and myself--but it was for the older version. I'll be updating it with the new steps. It doesn't really address how to troubleshoot, but I'd be happy to provide those when they're done if it'll help anyone else.

On a side note that is kind of unrelated -- for the hooks, if I wanted to do something like the nightly restarts, do I need to put 1101-nightlyrestartmaster as well as 9900-nightlyreset and 9901-nightlymerge or is it just the 1101?

Also, I just want to say that I am so glad for everyone who has contributed to this. I work for a library and the paid option for refreshing has become too expensive and some of the other freeware leads to BSOD on Win10. SS has been pretty easy to work with other than some trial and error and it does exactly what we need.

[unixabg]

Greetings,

The beauty of opensource is we can all work together to improve the project. So I do believe the step-by-step instructions would be considered for acceptance. Also there currently is a Rebuilding Steady State.pptx that is not up to date with the current code changes. Perhaps you would also consider improving that as well.

Ok now for the side note and hooks (ymmv disclaimer). Hooks were introduced to allow you to control the behavior of your deployments. See "How do first run hooks work?" in the README.md. Now I am assuming you are rolling back on reboot and you want nightly restarts. So before firstrun in phase 4, copy hooks-samples/9900-nightlyreset.cmd to hooks folder (those folders should be in the c:\srs directory). The 9900-nightlyreset.cmd creates a schtasks for 01:00 of shutdown /r /t 0 .

I hope this information assists.

[ngrl-librarian]

This is obviously quite a bit later--I don't have an issue or anything this time, but I do have those step-by-step instructions, finally. I made them shortly after finishing this conversation, but then life got crazy.

I'm not sure how to recommend them to be added, so I'm attaching them here and maybe you can help me figure it out or add it if they work for you. Update - How to Install Steadier State for Windows 10.pdf