JFX

The error comes from bcdboot.exe while creating the EFI bcd store. With this new leek, it creates an empty hive and than complains that it can not open the main key. Well this will be easy to fix, but i wonder why it happens.

Hi Holger, There is hardly any reason why it could crash after using tweaks options. What software do you have installed on your system? I remember TeamViewer as one app, that inject hook in other programs which tend to crash on window creation/destruction. @Atari800XL Just wonder, how is it if you try with proxy?

Updated to version 2.1 - file size trimmed down - added -windiff switch- added -xpwinload switch- added Windows 10 TP ADk

Changelog is also in the zip file as comment, if you use WinRAR for zip files.

It works here on WinXP, maybe you added a newer wimgapi.dll to the tools folder? Website is currently a bit slow but works.

Yes, in the original WTG, the drives are offline. But I decided to not do that, cause properly the half of the users would ask how to fix that.

Why you first wanted W: and now not? You can used this option as you want, it has no relation to WTG. EDIT: shuffling partition letters using WTG is normal, your WTG windows doesn't know how the offline windows has define drive letters for partitions.

If you set “Mount Installation drive as” to '*' than the system drive letter will not change. A stock Windows 7 will result in D:, and Windows 8 and newer usually in C: The preassignment option will save the drive letters of all fixed volumes. So for WinToGo this option is no use.

For change see http://www.winntsetup.com/news/ Yes, forgot to mention the "OA 3" lable if the PC have a MSDN table in BIOS/EFI

Hi RUSerious, there no extra option for Windows to go, just install it on a USB device. Can't say much about removable drives, never tried that.

Oh, yeah, there was something. I had that good idea to separate my FileExists() function into 3 more, like DirExist(), DeviceExists() and a universal PathExists(). But that also meant, to go through 31.597 lines of code and rethink all occurrence again ... Well at least I call it Beta

Patient? Well, I don't know, but I would call it grateful. You found 4 bugs in a couple of days. That more than most other report in a whole year. Anyway download problem should be solved. Was a quite evil bug, that corrupted a value, this time it lead to crash. Happy it's found and fixed now.

You download Dism 8.1 with GWT and put the DISM folder inside the Tools\x?? folder, there should already be a folder called DISM. If you want to save space, the api-ms-win-downlevel-*.dll should be enough actually. I check the download problem, when I back home.

@Atari800XL Instead of the the api-set folder there now one called DISM. You can still put only the api downlevel dll inside, to trigger the offline dism to do driver injection. It should work now, the tools folder wimgapi.dll is copied next to dism. Don't really know why it refused to load it from tools folder, it even searched there. However you can now copy the complete dism from latest ADK in the tools folders. This should avoid trouble with new Windows releases. @click-click it's a normal error, there no need to pay attention to it.

Well your Dism crashes cause there is no downlevel version of api-ms-win-core-libraryloader-l1-2-0.dll. The native (\Windows\System32\api-ms-win-core-libraryloader-l1-2-0.dll) one can't be used. So with one of the big updates dism was linked against this new library, however MS forgot to compile a downlevel version. Well this is something that have to wait til next year Properly the best solution will be to rely on ADK DISM. Well, that's just prime! So it was wimgapi.dll which wants to load that file. Fixing one rare occurring problem to rise an regular occurring one.

Oh, so let me guess you try installing one of the updated Win8.1 update 1, 2 or 3? And inside that new image there is no api-ms-win-core-libraryloader-l1-2-0.dll inside \Windows\System32\downlevel? But for sure there is one in \Windows\System32

Dism is one hell of a buggy software, all these error's would be crashing if the nice MS guy would do some error handling. Sadly I can't reproduce it, best would if you sent me a sysinternals process monitor log file.

Yes, on Windows 7 Host you'll need the aps-ms-win*.dll next to the wim or in the api-set folder. This is necessary to get the dism.exe from win8.1 or later running. If you running a Win8.1 system, they are not needed. The Vista driver integration should now work. There was a problem with pkgmgr command line. Also it behaves different than dism, if one specific a drive letter instead a folder path for drivers.

A versions mismatch should not make a problem here. Is this a mounted ISO or a stand alone WIM, With a normal ISO the \sources\api-ms-win-downlevel-*.dll files will be used for driver integration for Win8.1 out of win7. If not they have to be in the "api-set" folder inside winntsetups tools folder. Anyway try Beta2 It should fix at least the Vista and one Dism related problem.

Properly, I usually stay with one architecture, so I overseen this would happen. Tomoorw I check what happens with Vista, than it's about time for new beta

So, dism crashes cause there is no wimgapi.dll in \Windows\Syswow64 folder. Well this can be fixed quite easy. But for Vista, my last idea to use dism was wrong, it's not possible to use dism here for driver integration.

Driver ingratiation for Vista is a special one, as there is no dism on vista. Also I never tried WinPESE WOW64 for that Vista servicing. In next version I'll try to use DISM from current system.

Well, it's not that easy to explain how to get the offsets. But for your bootres.dll, seems it's also in bootmgr.exe, at offset 0x575C.

Well, you could check the Winntsetup.log in the windows directory. It should show which *.inf files were integrated and which not. Also there should be a Dism_stdout.log, too.

Yeah, better let's wait for Win10 final Well, bmzip.exe does compress better, so the new bootmgr will be slighlty smaller. I use the same compression code MS uses, so the size will stay more or less equal. Maybe next year I'll add "ABC" feature. This should be the offsets for 6.3.9600.16415 0000CF0E: 0F 900000CF0F: 88 900000CF10: AE 900000CF11: 02 900000CF12: 00 900000CF13: 00 90000194A9: 74 EB000194D3: 75 EB At address D84 you have the \Boot\BCD string that you can change.