Jump to content
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble
Strawberry Orange Banana Lime Leaf Slate Sky Blueberry Grape Watermelon Chocolate Marble

MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, register and become a site sponsor/subscriber and ads will be disabled automatically. 


  • Content Count

  • Donations

  • Joined

  • Last visited

  • Days Won


Everything posted by win32

  1. yeah, that also happened to me a lot. it's one of those things that got better over time.
  2. 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.
  3. 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.
  4. 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.
  5. I've had a similar problem a few times. It was fixed by disabling/reenabling the network connection from the network connections folder.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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!
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  16. 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").
  17. 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.
  18. I think this is the Windows 7 hotfix applicable to this situation: https://support.microsoft.com/en-us/help/2615701/-logon-process-initialization-failure-error-message-and-the-logon-process-does-not-start-in-windows-7-or-in-windows-server-2008-r2 But for some stupid reason it keeps redirecting me to a failed attempt to sign in to a M$ account. And of course the hotfix system has been dismantled so no attempts at comparison can be made between that and regular Windows 7 files, in order to backport to Vista. But I don't think that is the exact problem, as this is from late 2011 and Haswell was only released in 2013. And it also doesn't mention the behaviour where the logon process does initialize but other services don't. And I'm sure there are many people who are using Windows 7 without this hotfix and never having logon process issues on Haswell and later. It's not in Simplix pack and it doesn't appear that a future update superseded it unless the modifications made in this hotfix were discreetly carried over to later versions. But for what it's worth, it appears that the changes were mostly in kernel32.dll (which is broken up into several files on Windows 7) as well as the Local Session Manager. Plus WOW64 and Terminal Services. But I'm not sure what these changes are. I also found some potential registry-based solutions for dealing with individual services not starting up: https://support.microsoft.com/en-us/help/943996/some-services-do-not-start-in-windows-vista-and-windows-7 Also, did the logs/event viewer produce any information of substance? @burd And I just checked out 372.90's kernelmode (NVLDDMKM.SYS) driver. Only one function missing in ntoskrnl.exe, which is memcpy_s. The usermode Direct3D shim driver (nvumdshimx.dll) is missing the following functions in user32.dll: GetDisplayConfigBufferSizes QueryDisplayConfig DisplayConfigGetDeviceInfo Those functions are also called by the 372.70 version of the file. Maybe that's why you get such crappy D3D performance with those drivers! I'm definitely adding those ones to user32. UPDATE: turns out 365.19 also does call them. But they also don't support 1000 series where this problem happens. And MS is lying about DisplayConfigGetDeviceInfo being in Vista: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-displayconfiggetdeviceinfo I certainly don't have it and I do have every update up to Vista's EOL.
  19. I appear to have exhausted all reasonable options for modifying the import table aside from rebuilding it from scratch. But shell32 calls over 1200 functions so that is practically impossible. The procedure for doing this on x86 is considerably easier thanks to PE Maker. So I decided to call NtQueryInformationFile instead and now Waterfox Classic 2020.3.1 including e10s works. We are back on track. Even took a peek inside Server 2019's uefi.sys and dxgkrnl.sys. The latter has what appears to be calling dozens of functions missing from ntoskrnl.exe , yet uefi.sys only has about 4.
  20. Yes! So only user-specified programs can use the kernel extensions, which can easily lock out malware that relies on W7+ functions yet doesn't have local/manifests specified for it. I'd think that it would work for installers as well, as all program-linked libraries will call the local dlls instead of the system ones. Bootstrapped ones that check for OS versions are gonna be harder to work of course, but a few posts back I found a solution for new GIMP installers with general advice applicable to installers of such stubbornness. You can use Orca to modify/drop LaunchCondition tables in msi installers. For everything else, version spoofing through Application Verifier will work. In cases where a bootstrapped installer in a temp folder checks as well, you just need to get the name of that installer (but not path) and feed it to Application Verifier.
  21. Vista and Windows 2000 are the last two major revisions to the Windows NT kernel (NT 10.0 doesn't count since it was hastily bumped from 6.4 at the last minute and 1507 doesn't really add much from 8.1 win32-wise). Lots of major functionality that we take for granted, like USB mass storage support (2000), desktop composition (Vista) and proper NT DirectX support (2000) was introduced in those two OSes, with their minor kernel revisions adding relatively minor things or ones that were of poor quality, like XP's firewall and WLAN client; the former didn't support blocking outgoing connections and the latter doesn't support connecting to WPA2-EAP networks (or maybe it does but I couldn't manage it with the built-in client; had to use Boingo client that also works on Windows 2000). Vista fixed them both.
  22. You don't have to do so unless you're planning on replacing your system files with mine. With a manifest or local file in the program folder, it will simply use the modified files present in the program folder (if they're not present there, then it will look in x:\windows\system32 or syswow64). I'd like to say that in such a scenario, an old file of mine should work well with a newer MS file since the differences are relatively minor. ESR 68 seems to ask for nothing more than about 5 extra functions in user32. If they're simple enough (few import and subroutine calls within), I could have them done in a day! Nice. I use an HP Z600 with a Xeon X5670 for Vista (and Windows 2000)!
  23. Even in 2018 it was crazy; less than three years after Windows 10 was released, yet that's all my new HP laptop officially supported (what a mess that thing is). But if I bought a laptop in 2004, three years after Windows XP came out, I would have official support for not just XP, but 2000, 98 FE/SE and even NT 4 (ThinkPad T41)! And that laptop has sleep-related bugs with Windows 10 that the officially-unsupported 8.1/2012R2 doesn't have! Even with all of the MS lock-in, relatively few new win32 API functions have been added after Windows 8 so it looks like forcing software incompatibility with Vista exkernel/7/8.x will be difficult for years to come.
  24. I've got classic working partially (non-e10s and container tabs work); just need to get over the shell32 import table*/buffer overflow hurdle. I haven't touched Current but I've been looking closely at SeaMonkey 2.53.x and Firefox 68.9 ESR. Both use a few extra functions compared to Pale Moon and Waterfox Classic. *Stud_PE allows extensive modification of PE32+ import tables, but the first thing I tried was simply adding a function to the full import table. This created a new section with the new import plus dummy entries. Indeed, you cannot split an import table and thus seemed to mess up the file. I will try moving the import table, but Stud_PE can trigger DEP in that scenario. I'll try on my Banias Pentium M laptop. I have a Kaby Lake laptop that could be fit for that purpose. I do plan on installing Vista eventually (need to get a empty DVD-R!) to test a possible kernelmode extension that would support drivers designed for later versions of WDDM. The problem is that I still wouldn't have all of the material necessary for trying to diagnose the timing init problems, like a nullmodem/serial cable or even ports to debug the kernel from another machine using windebug. Would the problems occur when the OS is virtualized? Kernel debugging in such a case would be easier. And I heard someone say that same problem affected Windows 7 at one time. Further details about that fix would be helpful. Some users have been able to share Office 2013 ISOs from IA while others requesting W7 ISOs have been banned immediately. So I'd recommend erring on the side of caution. But I'm sure that others would be willing to promote it in their videos. No new functions seem to have been added recently to Vista's system binaries, and the security updates the files have received have made them slightly bigger. This will change the memory addresses of the new code thus causing the process to deviate slightly from those for the files I use, as most of the labour involved in extending the kernel is the result of adjusting memory addresses being called by instructions. To keep everything simple, I will provide WUC links to updates containing my versions of the files allowing everyone to play along regardless of update level. Perhaps I will provide updated instructions for the last versions of files once Vista ESU support ends.
  25. How will Tobin feel about this? There has only been one minor glitch where the title/URL/bookmark/tab bar briefly expanded when I was on YouTube. But I may have seen it before on 2012R2. Waterfox Classic 2020.3.1 is working too, but only in non-e10s mode (same as Pale Moon). I need to finish up SetCurrentProcessExplicitAppUserModelID in shell32.dll before e10s will work, it appears. I finished implementing CoGetApartmentType in ole32.dll, and it appears that dwmapi.dll is OK with stubs since the OS doesn't actually use the functions that newer Firefox-based browsers ask of that file. And there are some extra functions in user32.dll and uxtheme.dll that will be needed to make Firefox 68.9 ESR happy. More updates: K32GetModuleInformation will be added to kernel32 to accommodate SeaMonkey 2.53.x. And the thing that keeps e10s from working in Waterfox is that earlier one part of SetCurrentProcessExplicitAppUserModelID was bugged in a way similar to that of SetThreadErrorMode a few pages back. Problem is that NtQueryInformationProcess is not imported by the original Vista file, and there is no room to expand the import table (and I haven't found a good way to move import tables in x64 binaries yet). So first I tried adding NtQueryInformationProcess as a subroutine to shell32.dll. But that causes waterfox to crash with a BEX64 error (related to DEP/NX). And NtQueryInformationProcess has a syscall function in it. According to Intel 64 manual, syscall is a "Fast call to privilege level 0 system procedures". And as such, it is inappropriate for shell32 and should only be in ntdll.
  • Create New...