win32

I have decided to prioritize the x86 extended kernel over the x64 Haswell Logon Bug Fix as the latter is non-fatal, while lacking functions for x86 software is (unless you switch to a newer OS of course). Unfortunately there seems to be severe restrictions on what can be done to the x86 kernel32.dll. Unlike with the x64 one, you cannot put the export table wherever you like. And even moving the reloc and rsrc tables (plus the directory addresses) makes the PE32 image bad. So I cannot make a new section before rsrc that would house the expanded export table like in the 2000/XP extended kernels. At present my only solution is to remove seldom-used functions from the export table to ensure that enough room is present for mine. Nonetheless, oCam 511.0 is working (515 may work on vanilla Vista). You do it by the book and your hard work is rejected. update: After eliminating the debug directory and moving down the import table, I only have enough room for about four functions. Actually I can put the code in a section below .reloc like I've done with x64, leaving .text open for a bigger export table. But it would be rather difficult to move a thousand+ bytes worth of it. At least everything between 7DE37F10 and 7DE38F10. SECOND UPDATE: I was finally successful in placing a new export table section between .data and .rsrc without breaking the image. Here is the specific procedure: -Open up kernel32.dll in WildBill's PETool. Go to the .rsrc section. -Click "Insert section before..." on the Sections drop-down menu. Select your preferred name and size. -However, the section will not be the preferred size by default. To make it so, select "Consume slack..." from the Sections drop-down menu and press OK on the dialog that appears; the amount of slack expansion offered by default is the max. Any deviation from these three steps produces breakage! -Then use BWC's PE Maker to move the export table.

The July 2020 IE9 update for Server 2008 blocks Vista.

The update.exe module in the WhatsApp x64 installer is still 32bit. And I noticed they only support Windows 8 and above. Though it probably works on Windows 7 too since all Windows 8+ functions are currently in a broken state in my kernel. But I noticed that the application itself is stored in X:\Users\User\AppData\Local\SquirrelTemp\WhatsApp-2.2027.10-full.nupkg\. I extracted it from that package with 7zip and it ran.

That is the intention. I do believe that the logon init problems are connected to the random services/explorer having trouble starting. Though windbg hasn't helped at all. Sticking onto a VM with my file causes it to freeze when the boot screen is running. But I've noticed that BSODs ceased after making the wildcard import call RtlGetFileMUIPath, though it still causes automatic reboots. Others to try are: LdrGetDllHandleEx and RtlDetermineDosPathNameType_U, I also noticed that the Vista x64 implementation of LoadLibraryExW was very similar to the one in XP x64 (except for not calling SRWLock functions and some other minor differences), which doesn't have the same problem. Though I'm not sure if NT 5 versions of functions would be a good fit for an NT 6 kernel. Then I looked at the One-Core-API version of the function, where an auxiliary LoadLibraryExW is called in its kernelbase.dll, which leads back to the original one in kernel32.dll. Maybe I could use something like that. In the meantime I added K32GetModuleBaseNameW, K32GetModuleBaseNameA and SetThreadGroupAffinity. This will allow Logitech Gaming Software 9.02 and .NET 4.8 to work.

The version check is very complicated. First you must tell fcwin2k/nnn4nt5/Application Verifier x86 to trick the downloaded setup executable into thinking it's on 7 SP1. But then another version block appears, references W7, 8.1 and 10 1607+. This is done by a file named SetupShim.exe. For some reason I can't get around that. So I located the install files in X:\User\AppData\Local\Temp\PdnSetup. This appears to include the files needed to run the software. You can also run the two MSIs in the folder once you go into Orca and drop the "LaunchCondition" table. It will error out at the end but don't press OK: copy the files from the Paint.NET folder in Program Files (x86) to a safe place before the Windows Installer deletes everything. However, it appears that programs running under .NET 4.8 on Vista need SetThreadGroupAffinity (which is relatively easy to implement). I haven't tried with 4.7.

VMware Workstation 10-12 installers (and possibly earlier) will need the original Vista kernel32.dll. If they try loading with mine, then they proceed to call all kinds of absent ntdll functions. But 11 and 12 still do not install because the Windows Installer is apparently too old for them (do they need 5.0?). So it appears that a LoadLibraryExW replacement is needed to solve the Haswell+ logon bugs. The hotfix substantially changed the structure of the function beyond the changes between Vista and 7; these changes were carried over to all later versions of the function through at least Windows 10 1809, it seems. But as a such a crucial function to the OS, it is rather complex. Indeed, a full implementation of it as in the W7 hotfix would require two new functions (BaseGetProcessDllPath and BaseReleaseProcessDllPath) that in themselves are quite complex. So I tried substituting them for two functions imported from ntdll plus several other differences. This caused the OS to reboot several seconds after the boot screen had faded out (so before the orb appeared). So it looks like I'm going to implement the Windows 10 1809 version of LoadLibraryExW since it doesn't call those two functions. But it asks for LdrGetDllPath and RtlReleasePath, which do not even exist in Windows 7. RtlReleasePath is quite simple, but LdrGetDllPath is extremely complex. So I need to look for a suitable replacement for LdrGetDllPath. So far I haven't been able to do so (I tried RtlGetFullPathName_U), as I've only been able to get the cursor to appear before automatically rebooting.

You will have to use Application Verifier on Vista to fake Windows 7. In the case of an installer, you will have to track down the name of its temp installer file if they also do version checks. Once you have the program in Application Verifier, check the Compatibility box and then the HighVersionLie box under it. Right-click "Properties" on HighVersionLie and set your preferred OS version like 6 major, 1 minor, build 7601 etc.

I have received the Windows 7 logon failure hotfix as well as the set of kernel32/kernelbase dlls preceding the ones in the hotfix. kernel32 is very similar, with the only differences in the text (code) section of the file being in the debug directory. These differences are superficial, mostly consisting of changes in the timestamps. But kernelbase (which was part of kernel32 in Vista and earlier) is a very different story, with all kinds of small patches scattered throughout the text section. It may take awhile to implement. Tentatively, this seems to be an issue with a previous implementation of LoadLibraryExW. I have also finished implementing K32EnumProcess and GetActiveProcessorCount series in x64 kernel32.

yeah, that also happened to me a lot. it's one of those things that got better over time.

Yes, this bug also affects quotes on here. All of them are dated as "just now". So it appears that this bug appeared with my earliest revision to kernel32 this afternoon. I had commented out the Windows 8 function GetCurrentPackageId, but another one was fixed, GetSystemTimePreciseAsFileTime; that was previously typoed as GetSystemTimePreciseAsFileTIme. So I typoed it again and now the date problems and the download progress bar are fixed. Indeed, this is what this function consists of on Windows 8: retn 0 Makes me wonder how it could work on W8 in the first place. I also fixed up some code in a subroutine linked to the Power*Request functions. That fixes the Visual Studio Code CPU utilization issue.

I have done changes to uxtheme and dwmapi.dll (x64 in both cases) that strips them of any code associated to the new functions in each file, making them true stubs pointing to memory addresses far out of the file's range. Firefox 68 ESR and 78 (regular) are unaffected by the change, while the new stub-like properties of the functions do not affect logonui/winlogon in any way like my earlier attempts did, allowing for the OS to run with them. Windows Explorer is also stable with them. And furthermore, I got Firefox 68+ address and search bars working like normal after these changes! But it cannot automatically download Widevine CDM. So now I can focus on adding the last five functions (K32EnumProcess plus the ones in my post above) to x64 kernel32.dll. x86 kernel32 is actually quite difficult to modify in some way. Doing a "paste write" of the code into HxD like I do for x64 files breaks the x86 files in some way. And a "paste insert" seems to work, but it doesn't replace the existing zero bytes, it just pushes them farther down so to speak, making the file bigger and presumably why this would break an export table located below it (as I found to happen with x64 files where the export table was already relocated by me). update: actually there is another bug where the download progress bar is not updated in all browsers from Serpent/New Moon to Firefox 78. I'll investigate that one further. And some fonts on DDG in Firefox 78 didn't appear (perhaps they failed to download, possibly linked to Widevine CDM failing to download). In any event, you can still redirect Serpent and New Moon to the original Vista DLLs. These problems seem to be linked to kernel32.

Have you tried the Boingo client? I used that exclusively after installing the extended kernel. I remember the native Intel wireless manager was quite useless to begin with (used a 3945ABG WLAN adapter) and it may have had the same issue as you, but I cannot confirm since that laptop has its own issues now.

I've had a similar problem a few times. It was fixed by disabling/reenabling the network connection from the network connections folder.

MPSS is only compatible with Windows 7 and above. Its driver is only available for x64 systems: https://software.intel.com/content/www/us/en/develop/articles/intel-manycore-platform-software-stack-mpss.html?wapkw=mpss#about https://www.pugetsystems.com/labs/hpc/Intel-Xeon-Phi-with-Windows-510/ You cannot run Windows applications natively on the Phi, as the Phi itself runs on an embedded Linux.

Perhaps. It would have to be implemented through the NTFS/ReFS drivers. My confidence is low since my success rate for kernel mode extensions is still 0%, But I have tracked down what appears to be the functions referencing "DisableDeleteNotification" and "DisableDeleteNotificationDrain" in the 2012R2 ntfs driver; fsutil querys "DisableDeleteNotify" to check TRIM status. So a backport is possible.

I'll add GetActiveProcessorCount (plus associated functions GetActiveProcessorGroupCount, GetMaximumProcessorCount and GetMaximumProcessorGroupCount) once I get back to the x64 files. My x86 kernel32.dll is about 25% finished. I am holding off a wider release until the x86 files are completed and a few bugs are fixed.

No. It doesn't have enough functions for BWC's kernel32.dll (so it can't boot with it) and his extended kernel doesn't have enough functions for New Moon/Serpent either.

I've narrowed this down along with other similar limitations. The system lockups are due to me running in debug mode; in fact, pressing PrintScreen will lock up the system! The only issue with dependency walker/debugging of programs using my extensions is that trying to track GetProcAddress/LoadLibrary functions will cause a buffer overflow exception. Aside from that, debugging with redirected DLLs is very possible. The obvious solution is to replace the system files with mine, which I was able to do early on, yet now it appears that winlogon/logonui can no longer accept them. And they don't redirection. While Brave and its main DLLs don't seem to export any W7+ functions from DLLs other than kernel32.dll, I decided to copy the rest over and now get a fault in kernel32 at 78DFEC00h, which corresponds to an import table entry for RtlFreeOemString ("Frees the string buffer allocated by RtlUnicodeStringToOemString.") from ntdll, which is called by two subroutines in kernel32. Further investigation required. Visual Studio Code now works, not hindered by my unfinished implementation of Shell_NotifyIconGetRect, but thanks to the fixing of another bug in another function I implemented. Do not, under any circumstances, try to reimplement ntdll functions in other DLLs (except for ntdll functions that are forwarded from kernel32, in kernel32)! There are issues though, with the module that implements extensions/plugins, spdlog.node. It uses up lots of CPU time bringing CPU usage to ~94% on my Xeon X5670. I'll try that soon, once I get the x86 ball rolling, since there doesn't seem to be any x64 binaries available for Windows. In fact, my earlier post about shelving MS Edge and Office 2016+ due to disobedient installers was in error, since I just checked and found that the installers are indeed 32-bit. I've turned into Tim Apple with his OS' relentless pursuit to abandon 32bit binaries. Actually Windows 7 x86 kernel32 code is far simpler than the x64 equivalents, so I have an even better feeling about it. Just need to work quickly enough before x86-32 everything is deprecated!

That was version 11 on Windows 2000, which exhibited some other deficiencies compared to it on XP. But you should try updating the root certificates.

Unfortunately things aren't working out with Brave: And I have identified two conditions that may cause a system to lock up; first, running chrome_pwa_launcher.exe from Brave's folder or attempting to use Netflix in Firefox 68 ESR and later. In the second case, it seemed to be due to GetCurrentPackageId, which is a Windows 8 function. Firefox also does exhibit completely different behaviour if tricked into thinking it's on 8.x, as most UI elements don't work in that case. You can disable buggy functions by opening your local copy of a dll in ExportTableTester, and simply changing "XXXXFunction" to "XXXXFunctio_". But Electron-based Visual Studio Code seems to be in a better place. The only thing holding that back is my incomplete implementation of Shell_NotifyIconGetRect. All I have to do for that one is add a chunk of the function (as in a part that is separated from the rest), two subroutines with a chunk each, as well as a couple of new qword values in the data section. Luckily, all of its imports are accounted for in the Vista version. I can't think of a good, modern Chromium browser to try. It seems that they are all undesirable in some way, and their only good purpose is to view heavily-DRMed content that roytam1's or Tobin's browsers can't handle. With the expanded complexity of the project in mind, I have scrapped the idea for the tutorial. I am working on alternative means of distribution for the kernel extensions. Please contact me for more information.

That doesn't actually change any hex values, just the way it is displayed to IDA. So it doesn't actually change locations. And I'm unable to run New Moon/Serpent with ntdllx4 as they throw exceptions in kernel32.

Heads up about Firefox installers (78.0.1 to be exact). To install, add "setup.exe" to the list of applications in Application Verifier x86 and adjust version settings accordingly. Firefox 68.9 ESR is mostly working, except for a quirk involving the address/search bars. There are no default search engines and no way to add them. Thus, if you want to load pages directly from the address bar, you have to specify the protocol (like http;// or ftp://). Please note that the uxtheme.dll I'm using is a little stubby, but it does seem to be a far-fetched link. And I'd think that uxtheme would be OK being stubbed as, much like with dwmapi, uxtheme only needs to accommodate themes compatible with Windows Vista and not those for Windows 7. Perhaps some more debugging is needed. As for 78.0.1, it appears we will now need K32GetPerformanceInfo in kernel32.dll. The Firefox executable now also calls for RtlQueryPerformanceCounter in ntdll.dll. The thing is that, ntdll seems to be untouchable in NT 6.0! There's tonnes of extra data beyond the specified sections, which CFF Explorer does not handle gracefully. Stud_Pe does recognize the extra data, and makes new sections beyond it. But I still haven't tried adding any code since, as RtlQueryPerformanceCounter can easily be substituted for something like NtQueryInformationProcess. In fact, now that I extended kernel32.dll and modified firefox.exe, it seems to work similar to 68.9 ESR with the same bug. I'll get to the bottom of this! UPDATE: Turns out that windbg still works with my kernel extensions. So, this is what happens with Firefox 68.9 ESR: Where is search engine information stored in modern Firefox? Furthermore, it thinks I have no Windows Media Foundation. Maybe if I extended it (mf and mfplat.dll) it would work. Maybe. And now for Visual Studio Code: to install it, add VSCodeUserSetup-x64-1.46.1.tmp (or whatever the exe is called, just with a tmp at the end) to Application Verifier x86. It needs these functions: shell32 Shell_NotifyIconGetRect user32 ChangeWindowMessageFilterEx SetWindowDisplayAffinity kernel32 PowerClearRequest PowerCreateRequest PowerSetRequest QueryUnbiasedInterruptTime RaiseFailFastException K32GetMappedFileNameW (this one is for Brave browser based on Chromium 83) But apparently Office 2016+ and MS Edge installers (click-to-run) don't like local files, so they won't install.

I could see them calling reg keys like HKLM\Software\Microsoft\Windows NT\CurrentVersion and calling KeBugCheck or something similar if they saw (or did not see) a certain version. But I don't think that happened in that case. https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/bug-check-0x139--kernel-security-check-failure Yours had a 3 in parameter 1, so a corrupted LIST_ENTRY. But the issue seems to only be restricted to Windows 8's dxgkrnl.sys; there seem to be no issues with the ones in 7 and 8.1. Perhaps the last working and first broken driver need to be compared, or dxgkrnl.sys needs to be replaced with a 7 or 8.1 version (preferably 8.1). There must be some differences in 8's dxgkrnl.sys compared to the 7 and 8.1 versions, and perhaps the driver no longer accommodates for that one since it's no longer a targeted/supported platform. More specifically, DXGCONTEXT::SubmitPresentHistoryToken needs to be compared between the three OSes. Going back to Vista, I admit that the road to an extended ntoskrnl.exe/dxgkrnl.sys/etc will be tricky. Even with Windows 2000's kernelmode driver extension, some XP display drivers were quite unstable in certain games; BWC had to edit the drivers further to improve functionality. But it will be interesting to see how far we go.

PE Maker is incompatible with x64 files. While it will show some basic information about x64 files, you cannot edit them nor manipulate their import/export tables. Use CFF Explorer to change the subsystem versions (they will appear in the table that appears after clicking "optional headers").

I looked at the Vulkan driver (both vulkan dlls in VulkanRT-Installer.exe) and it doesn't seem to have any dependency issues on Vista. I'm stuck on a GTX 260/Quadro FX 3800 so I can't test anything though. Perhaps the Vulkan applications have their own compatibility issues? Though, while I'm at it, here are the missing functions in ntoskrnl required for Skylake graphics: strncpy_s wcscpy_s IoUnregisterPlugPlayNotificationEx swprintf_s strcpy_s RtlUnicodeToUTF8N vswprintf_s _vsnprintf_s vsprintf_s _snprintf_s KeSetCoalescableTimer strnlen sprintf_s strcat_s memcpy_s wcsncpy_s Most of these functions exist in Vista but without the "_s" appended to them.