WildBill

Ugh. Here's another that fixes a bug in parsing "NOGUIBOOT" and clears direction flags when messing with the palette (if they weren't already cleared that would be a big problem). Windows2000-KB2393802-v1-early-c5n-x86-ENU.exe

Unfortunately I can't recreate the problem so I'm trying to find it by eliminating potential causes. Here is another one that (1) removes the call to load the image from the registry, (2) removes the call to load the image from disk, and (3) puts in a small fix when setting up the image palette. Windows2000-KB2393802-v1-early-c5m-x86-ENU.exe

The thought has crossed my mind, though I'd still like to try a little more to fix it once and for all. I've been out of action with a virus for the past week, hence the lack of updates (and I still have it -- physical virus, not a computer one). The time has allowed me to think about where tomasz's problem might be coming from. I put together this update which leaves everthing in place but circumvents loading bootskin settings: Windows2000-KB2393802-v1-early-c5l-x86-ENU.exe

Hmm. There aren't many things left to try. Here's one that adds guards around the palette code: Windows2000-KB2393802-v1-early-c5k-x86-ENU.exe

Almost there Here's another one that changes how it tries to load the bootskin image from disk to use a lot less stack space. Even if you have bootskins off it was still allocating a lot of stack space and maybe that was a problem. Windows2000-KB2393802-v1-early-c5j-x86-ENU.exe

Ah-ha. I think I found the reason why you weren't getting a boot screen with /SOS off. Also, I have a hunch as to why it' dying at 80%. Here's another test: Windows2000-KB2393802-v1-early-c5i-x86-ENU.exe

What do you get without /SOS? Does the monitor go off at about the same point? (80%)

I think I found something -- a variable that I wasn't initializing if custom bootskins were turned off. Maybe this will help: Windows2000-KB2393802-v1-early-c5h-x86-ENU.exe

Hmm. Maybe it has to do with moving a couple of routines. I moved them back while keeping the mods to them...maybe this will do something. Windows2000-KB2393802-v1-early-c5g-x86-ENU.exe

(sigh) Here's another that switches one routine off. There's so much ruled out now that there can't be much left to cause it. Windows2000-KB2393802-v1-early-c5f-x86-ENU.exe

Sorry I had forgotten to change the access flags for one of the sections, which almost certainly caused the bluescreen. The IAT table size was also too small, though that probably didn't cause it -- I fixed that too, though. Windows2000-KB2393802-v1-early-c5e-x86-ENU.exe

Okay, here we go. I hooked in the bootskin code for the multiprocessor kernels. If this works, the last step will be redoing the uniprocessor ones. Windows2000-KB2393802-v1-early-c5d-x86-ENU.exe

I do it manually

Here's one more test This one has all the necessary changes to the input table and basically does everything short of hooking in the bootskin code. If this works, the next one will be a complete V4 for the multiprocessor kernels (and if that works, I'll make the same changes to the uniprocessor ones). Windows2000-KB2393802-v1-early-c5c-x86-ENU.exe

I'm thinking that the way to proceed is to redo v4, but without having to change the file and section alignment values. Here is a v1-early-c5b that has all the new bootskin code added, but none of it is connected. However, it also has the separate .skin section that I need and combines two data sections so I could add the skin section without having to mess with the header size or alignment values. Windows2000-KB2393802-v1-early-c5b-x86-ENU.exe

Gah. I crawled through the /SOS code and I can't find anything wrong. Let's test something else. Here is an early c5a that is the same as c5 but with one change: it increases the image size by the amount that I need for the scroll buffer. I want to see if the larger kernel size is causing a problem. I can't see why, but nothing else makes sense so far. Windows2000-KB2393802-v1-early-c5a-x86-ENU.exe

Hmm. Here's a v4-test 3 to try. I'm not sure if it will help, but we'll see. I changed a lot of the code that saves registers to be super-paranoid and save them all. I only made the change to the non-PAE multiprocessor one, so you'll have to have PAE off and be using the MP kernel. Windows2000-KB2393802-v4-test3-x86-ENU.exe

Forgive me if you mentioned this before, but do you get anything if you add /BOOTLOG to boot.ini?

Hmm. I'll have to do some more analysis then. So just so I can be sure to understand: when you have /sos on, do you get any graphical display at all after it's done with the text-mode "starting windows" stuff (e.g. the Windows 2000 Server banner at the top, empty progress bar, etc.)

Ok... that rules out some more potential causes. When /sos on, does the progress bar still reach 100%?

I expected the progress bar issue: the values are never getting set, so they're defaulting to 0, 0. But if you got the progress bar, then doesn't the default boot image also show up? I'm confused...is the problem that the boot screen never shows at all or that the system freezes at some point?

Ugh. Ok, here's a V4-test2. It has all the V4 stuff but has bootskin support disabled. Still, it will test some of the altered code that supports bootskins even if custom settings are disabled. Windows2000-KB2393802-v4-test2-x86-ENU.exe

What if you set boot.ini and then install one? (not slipstreaming)

Is this with V3 or V4-test1, or with the early ones? The early ones won't do anything with them since there's no bootskin code in there.

Hmm. That suggests a problem in the boot skin support. Let's try this: 1. Do you have any /bootskin settings in your boot.ini? 2. What happens if you add something like this, using V3 or V4-test1: multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect /bootskin=0 Or this: multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows 2000 Professional" /fastdetect /bootskin=1:0:0:0:0:0:416:640:10:4