WildBill

A-ha...the original ntkrnlpa had a stack variable in a different place than in the other three files, and it affected the SOS setting (and probably caused the BSOD). This might help: Windows2000-KB2393802-v5-early-2-x86-ENU.exe I also checked the multiprocessor PAE kernel, and that one looks ok (the variable's location is the same as the non-PAE one). Go figure.

If your desktop is multiprocessor, then its PAE kernel is ntkrpamp.exe (which gets renamed to ntkrnlpa.exe), whereas the laptop's uniprocessor PAE one is from ntkrnlpa.exe (i.e., they're different). Actually, that info helps a lot: it means that I probably messed something up in the uniprocessor PAE kernel. Hopefully it will be easy to find.

Here's something to try...ntoskrnl was a bit different than the other three in that it had some extra changes when I was still working out how to hook in the bootskin code. I undid those extra changes so it matches the others, and I altered the bootskin code very slightly to better restore ESP (in ntoskrnl only for now). I don't see any reason why this would help as I didn't see any obvious issues, but it's worth a try. I've tested it in a VM with no issues. This is an early build of V5 that adds some new functions to ntdll and kernel32, but there are some more things I'd like to add before making it an "official" v5. I'm using it here on my laptop with no problems, so for the adventurous it adds the following: ntdll RtlAddVectoredExceptionHandler (also involved updating LdrpInitializeProcess and RtlDispatchException and adding internal function RtlCallVectoredExceptionHandlers) RtlRemoveAddVectoredExceptionHandler (also involved updating LdrpInitializeProcess and RtlDispatchException and adding internal function RtlCallVectoredExceptionHandlers) kernel32 GetSystemTimes CreateMemoryResourceNotification QueryMemoryResourceNotification AddVectoredExceptionHandler (forwarded export to NTDLL.RtlAddVectoredExceptionHandler) RemoveVectoredExceptionHandler (forwarded export to NTDLL.RtlRemoveAddVectoredExceptionHandler) Windows2000-KB2393802-v5-early-1-x86-ENU.exe

Ask and ye shall receive... see the top post

What happens without /SOS? Same thing? Another dumb question: is /BOOTLOG set? Are you using any bootskin settings? Okay, after spending the day investigating, it looks like ESP (stack pointer) must have become corrupted somewhere, and then an interrupt occurred (most likely from a driver, which wouldn't be loaded when you're in safe mode). So now, the trick will be finding whatever is corrupting ESP yet doesn't result in a BSOD all the time (maybe the routine in question recovers the correct ESP before it returns?) It's pretty hard to screw up ESP and not generate a GP fault when returning from a routine.

Hmm. I'm going to need some more info to track that one down, since the address is pointing to a trap routine (specifically, it traps 0x57, which I assume means int 0x57). When does the BSOD happen? Does it create a minidump file? It looks like it trapped an interrupt (maybe from a driver?) and it didn't like it. The 0xC0000005 means ACCESS_VIOLATION, so I assume that it tried to access an invalid memory location. The problem is going to be finding where it happened. Edit: it looks like int 57h is a relocated IRQ7, so maybe a driver that's using IRQ7 is causing the problem. The interrupt request for a driver is shown under the Resources tab in the Device Manager. It's also possible that it's really IRQ15, from a secondary interrupt controller.

tomasz: just as soon as you can give me the all-clear for V4 I'll consider that a green light for V5 (I've already started on it and added a few more routines to ntdll and kernel32)...

Fyi...My MS11-011 patch adds EncodePointer and DecodePointer. blackwingcat's kernel v5 does so as well.

I finished porting the changes and the patch is working here, so I've posted MS11-011 v4 and updated the link on the master list. For the record, the complete list of new API calls the patch adds is: ntoskrnl.exe/ntkrnlpa.exe/ntkrnlmp.exe/ntkrpamp.exe KeAcquireInterruptSpinLock KeReleaseInterruptSpinLock InterlockedPushEntrySList InterlockedPopEntrySList RtlInt64ToUnicodeString RtlIntegerToUnicode RtlClearBit RtlTestBit RtlSetBit ZwQueryInformationThread......already there, added it to the export table IoForwardIrpSynchronously/IoForwardAndCatchIrp (same routine, has two different exported names) PsRemoveLoadImageNotifyRoutine (had to completely redesign the set and call routines to make this work) PsRemoveCreateThreadNotifyRoutine (had to completely redesign the set and call routines to make this work) _vsnwprintf _aulldvrm RtlGetVersion KeFlushQueuedDpcs ntdll.dll RtlIpv4StringToAddressA RtlIpv4StringToAddressW RtlIpv4StringToAddressExA RtlIpv4StringToAddressExW RtlIpv4AddressToStringA RtlIpv4AddressToStringW RtlIpv4AddressToStringExA RtlIpv4AddressToStringExW RtlIpv6StringToAddressA RtlIpv6StringToAddressW RtlIpv6StringToAddressExA RtlIpv6StringToAddressExW RtlIpv6AddressToStringA RtlIpv6AddressToStringW RtlIpv6AddressToStringExA RtlIpv6AddressToStringExW RtlInitializeGenericTableAvl RtlIsGenericTableEmptyAvl RtlGetElementGenericTableAvl RtlNumberGenericTableElementsAvl RtlInsertElementGenericTableAvl RtlDeleteElementGenericTableAvl RtlEnumerateGenericTableLikeADirectory RtlLookupElementGenericTableAvl RtlEnumerateGenericTableWithoutSplayingAvl RtlEnumerateGenericTableAvl RtlEncodePointer (not a stub -- it's the real functionality and depends on changes to ntoskrnl.exe, etc.) RtlDecodePointer (not a stub -- it's the real functionality and depends on changes to ntoskrnl.exe, etc.) RtlInterlockedPushEntrySList RtlInterlockedPopEntrySList RtlInterlockedFlushSList RtlQueryDepthSList RtlInitializeSListHead LdrLockLoaderLock LdrUnlockLoaderLock LdrAddRefDll RtlComputePrivatizedDllName_U RtlValidateUnicodeString RtlDuplicateUnicodeString RtlDowncaseUnicodeChar RtlFindCharInUnicodeString RtlpEnsureBufferSize RtlMultiAppendUnicodeStringBuffer RtlAppendPathElement LdrEnumerateLoadedModules RtlRandomEx RtlUnhandledExceptionFilter2 RtlUnhandledExceptionFilter bootvid.dll VidSetVgaPalette (used by the bootskin code) kernel32.dll DecodePointer (forwarded export to NTDLL.RtlDecodePointer) EncodePointer (forwarded export to NTDLL.RtlEncodePointer) InterlockedPushEntrySList (forwarded export to NTDLL.RtlInterlockedPushEntrySList) InterlockedPopEntrySList (forwarded export to NTDLL.RtlInterlockedPopEntrySList) InterlockedFlushSList (forwarded export to NTDLL.RtlInterlockedFlushSList) QueryDepthSList (forwarded export to NTDLL.RtlQueryDepthSList) InitializeSListHead (forwarded export to NTDLL.RtlInitializeSListHead) GetModuleHandleExA GetModuleHandleExW IsWow64Process IsWow64Message GetProcessHandleCount GetNativeSystemInfo (same as GetSystemInfo, simply added another export table entry) SetDllDirectoryA SetDllDirectoryW GetDllDirectoryA GetDllDirectoryW AttachConsole TzSpecificLocalTimeToSystemTime SetClientTimeZoneInformation IsValidUILanguage GetSystemWow64DirectoryA GetSystemWow64DirectoryW SetHandleContext GetProcessId EDIT: forgot to list a couple of extra routines I added to ntdll.

If the checksum is wrong, it won't even load: you'll get an error saying it's missing or corrupted. I've started porting the changes to the other files, so I'll be able to test it over the weekend. The V3 one worked here last time I checked...

The uniprocessor one definitely won't work as I haven't migrated the changes to it yet. Only the non-PAE mp one is "done". I wanted to see if you give it a good bill of health on the bootskin stuff before updating the other three files.

Oops Mistake on my part. I messed up how I was testing the flag. Windows2000-KB2393802-v1-early-c5q-x86-ENU.exe

Hmm. What were the bootskin settings?

Would you mind testing a bootskin to see how that works out?

Okay, here's the acid test. This has all of the bootskin code enabled and has the scroll buffer renamed to .xdata to protect it. If this works, then over the next few days I'll make the same changes to the other three files and release a V4. Windows2000-KB2393802-v1-early-c5p-x86-ENU.exe For what it's worth, v4 also adds a few more routines: _vsnwprintf _aulldvrm RtlGetVersion KeFlushQueuedDpcs

That was it probably. It works now Do you have any idea why this issue was present here and not anywhere else? Could it be hardware specific? I think so. It looks like it only turns paging on if the memory address is not within a certain area. Maybe your hardware combo is resulting in the kernel being loaded into a different address.

I might have found something. Apparently, at the 80% mark, the kernel decides that it wants to make certain of its memory sections pageable, including the one I'm using to hold the larger scroll buffer. That's fatal to the bootskin code because the buffer must not be pageable. I renamed the section in question from .edata to .xdata to keep the kernel from doing it. Cross your fingers... Windows2000-KB2393802-v1-early-c5c8-x86-ENU.exe

Actually, that's good news: now I have something to focus on.

Hmm. I didn't have write access turned on for the larger buffer, so this might be a false alarm. What happens with this one, with writes enabled? Windows2000-KB2393802-v1-early-c5c7-x86-ENU.exe

A-ha! Now we're getting somewhere. Will look at it tonight.

Okay. Next change: switching to the larger scroll buffer... Windows2000-KB2393802-v1-early-c5c6-x86-ENU.exe

Good One more change: loading bootskin settings (but not doing anything with them): Windows2000-KB2393802-v1-early-c5c5-x86-ENU.exe

Wow! Makes me tempted to buy a copy of O2k7...I'm still using O2k. Here's another very tiny step. Just moving some instructions around to their final positions: Windows2000-KB2393802-v1-early-c5c3-x86-ENU.exe

It happens when I enable all of the bootskin support, but the problem has been tracking down the exact cause. For this test, I went all the way back to c5c since that was the last one that worked (it didn't have the bootskin code hooked in). This one hooks just one tiny piece in (actually just a helper routine, not really bootskin related). Maybe I can connect the bootskin stuff one tiny piece at a time until it fails. For now, I'm only going to update ntkrnlmp.exe since that's the one that tomasz uses. Windows2000-KB2393802-v1-early-c5c2-x86-ENU.exe

(sigh) I went through all of the bootskin code and revamped how I deal with the stack -- except for two particular routinea, this one takes a minimally-invasive approach instead of saving everything in sight. Windows2000-KB2393802-v1-early-c5o-x86-ENU.exe