joakim

It should be even easier with my custom version as it is not compressed, unlike the original bootmgr. The tools you refer to in that referenced thread will thus not work on my version as the offsets are hardcode in the program. Since I don't have the file at hand at the moment, I can't really say at which offset you must modify. But I will get back to it. Otherwise, just open the file in a hexeditor and search for the string boot\bcd for which you can modify to your likes. I've tried paths like 1\a\2\b with success in the past, which means you are not restricted to the boot folder. Joakim

If someone with very good knowledge about the $LogFile is aroung here, then please join this thread. If we could decode the structure of that metafile (or just the header of it), then I am quite sure boot.sdi could be reduced close to 60 Kb. Joakim

Well that was the first thing I tried, but realized it did not work, and got bsod with PROCESS1_INITIALIZATION_FAILED. I'm more positive to patching the kernel to not load hives as volatile, but am still failing. Have tried like 5-6 different places now. Winpeshl.exe has nothing to do with it. I replace it with cmd.exe as specified in the registry key CmdLine. Modifying the MiniNT string in the kernel does not help either, and neither does the removal the 2 WinPE keys, or even preventing the kernel from writing the MiniNT key under Control key (if you string replace MiniNT, it will still write the new name instead of MiniNT. I suspect the right way is to force write a 0/1 into the al/bl register at some place. Thereby fooling the kernel to think non-PE -> non-volatile hives. Just need ti figure out exactly where.. Btw, are we sure that the log files are in fact properly flushed (merged to hive) when shutting down with wpeutil.exe/shutdown.exe? Could also mention that changing the string Control\MiniNT to Control in wpeutil.dll will let you run all the PE utilities /winpeshl, wpeutil, wpeinit) with winpe=off. Joakim

I believe I found some interesting code inside the kernel to possibly activate non-volatile hives in WinPE. To late now, but will try some modfications when time allows. Joakim

What's wrong with the original winpeshl.exe? Don't expect me to write a loader as I have no idea.. Sources for most bootfiles pm'ed. Joakim

I'll send it to you later on today.

Yes I made a winload patcher that I posted at the sanbarrow forum. It works good for this job. Actually the best thing would be to use the original non-PE SYSTEM hive for WinPE, which contains system services and more. I tried tweaking that in almost any imaginable way, but did not completely boot. It just froze with a black screen after all boot drivers where loaded. Then only using the SAM and SECURITY hives from WinPE would be the goal. 1 tip when working with hives like that. Sometimes it's easier to export separate parts from the original hive into reg files. Unload the original and load up a new empty hive where you can import all the reg files. This way you don't have to fight with permissions, which can be a pain in the back, and you can delete anything you want. Joakim

Congratulations with a great builder. Built my first samples and I'm really impressed. Though only on 1 testbuild, but anyways good. May I suggest something to reduce size further: Remove all log and transaction files (.log* .blf .regtrans-ms) inside the config folder where the registry hives are located. We don't need them and can safely be deleted. In my case I save14,5 MB uncompressed. Then unless you really want the animation, delete bootres.dll (over 2 MB). However, on the other hand, if you want to keep the boot animation, why not improve it. Make your own special one... Will do more tests, but really looking good! Joakim

Ok so I managed to boot both systems into C:\ with almost the same sources. Had to replace the SAM and SECURITY hives with the PE ones. But with the same SOFTWARE hive. Possibly it could be easier to make the config folder of WinPE point to something different and hardlink the SOFTWARE hive back into the default/original. Cool, but maybe not very useful. Interesting to see that the differences don't necessarily are that big.. Joakim

Yes WinPE can easily be run from C:\. Do not need to remove fbwf. Just added 2 (I think) missing drivers. Can give it another try later on by removing those folders and the files you mentioned.

Like I said it did not bsod, crash or reboot. It just froze with the text I mentioned. The test was to boot both systems with the same SOFTWARE hive, but 2 different SYSTEM hives. Also tried patching the kernel to load alternative software hive, but that crashed with bsod 0xc000021a. Joakim

The registry tweak to specify systemroot in winpe works inpedependent of the medium that it comes from. The second part about the 2 merged systems was just another test I did. For that you need both the systems on the same medium. In my case for the test, I just did a plain flat boot from HDD, ie no wim. Of course in vmware. Joakim

They have disassembled the files in IDA. Then loaded the pdb files with debugging information (symbols). And finally exported c-like code with the hex-rays plugin. Joakim

Maybe it's old news and I've missed it, in which case forget about my post. Anyways, I noticed that you can specify from which drive to run your winpe from by tweaking the registry. At a minimum this is required; Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\WinPE] "InstRootDrive"=dword:00000043 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinPE] "InstRoot"="C:\\" And a few more would be required to change since some paths that are hardcoded by default. But the rest is only needed for every component to work completely. This is only tested on version 3.0 of WinPE. Then I took it a bit further and tried to "dual boot" Windows 7 and WinPE 3.0 from the same systemroot (ie from C:\). By patching winload.exe you can load alternative system hive, so that you have 2 different ones to choose from. Then run both systems from the same SOFTWARE hive, by adding the above mentioned code to the software hive. This way the WinPE will not write anything to the local registry hives, as changes are never written back to disk. Now sadly I didn't boot fully, but at least it did not bsod, crash or reboot. It just silently froze with nice text on screen saying; "Setup is starting services", roughly at about where winint.exe would be launched. This was just for the test, and I'm sure people know better than trying this on a real system. Joakim

I was hoping to test out your tool later today (which was about time). Now what is the current state of dotnet support? And what about bluetooth? Joakim

I suspect it comes from the ssdpsrv service. If so then it may relate to the upnp configuration in the router. Maybe you don't even need it.. Joakim

And if you're looking for updates on the topic (or details), then follow the main thread; http://forum.sanbarrow.com/viewtopic.php?f=85&t=15 Joakim

I'm quite sure jjm369 does not bother with this multibooting task anymore after +2 years, but I accidentally ran into this one and thought I could mention for those wondering that a solution now exist; http://forum.sanbarrow.com/viewtopic.php?f=85&t=15 (yes I know I already have it posted in the Windows PE section). Joakim

JFX has provided an excellent tool to generate your menu.lst based on a target wim. Joakim

The referenced thread (first post) now contains complete descriptions with lots of details, as well as my sample menu.lst covering 4 different images. I would say it's now a fully working solution. Joakim

Hi John I answered at the sevenforums; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a-32.html#post1059879 Joakim

Here's the link to the thread where information can be found on how to get uncompressed bootmgr; http://sanbarrow.com/phpBB2/viewtopic.php?t=1696 If you for some reason want to experiment with decompressing/recompressing the original, you will also find a post there with a link to a tool that can do so. Basically you just grab bootmgr.exe (otherwise known as pxe version) remove some unneded bytes to reduce its size and attach an older vista sp0 stub. Oh and you will need to patch some integrity checks as well so that the modified bootmgr will load without complaints. That is 1 checksum check in the stub as well as the selfintegrity check in bootmgr (validating the digital certificate). There's many ways to solve this, but the one I'm currently using is by patching in two nops (9090) at VA 421EC5. Joakim

For those interested in the details, it can be found here; http://forum.sanbarrow.com/viewtopic.php?f=85&t=15 The point is to modify bootmgr so that the wim header gets patched in memory after it is read by bootmgr. It is a proof of concept, and not very elegant. It is required to know your target wim and the images inside it. When you know that, you can put the magic bytes inside menu.lst and map bootmgr to the rd device and patch it there. Well, read the thread and get the details. The point is it is possible to boot off any image inside your wim. It does not have to be specified as the boot image in the wim header. Joakim

By the time you have finished reading this thread; http://www.sevenforums.com/customization/106861-how-change-boot-animation-windows-7-a.html , you should be able to tweak almost every part of the boot process up until the kernel has taken completely over. Joakim

OK, looks like I need to study some more, and realistically not having it decoded in a short time (if ever). Joakim