jumper

loblo's crash is in the XTREE code, while schwups's crash is in sstring, however, all roads are leading back to a failure in the 'new' constructor. 'new' is implemented via HeapAlloc, so I've made the heap growable and added the HEAP_GENERATE_EXCEPTIONS flag to HeapCreate. I've also tweaked my stack dump code so it should work better. And it should appear just once right before the main crash. schwups, please also include the standard error text as it contains the register values needed to fully trace the assembly code. For everyone not experiencing mprexe problems, I've added 78 new Ntdll function forwards, all needed by something I've tested in the last year (including IE8, KM74, and ReactOS). Release_5.7z 4_5_2015_5_source_diff.7z

Release.4 sources posted above. Release.5 will have 77 new Ntdll forwards to Msvcrt (from my stubs.ini!) About 19 dlls from ReactOS should now load. Processing the debug data now. Looks like we may multiple issues. Thanks, everyone! p.s. Cloudme should now load in Slimboat, but be prepared to wait if you have a slow connection or computer--they are both very slow!

Avoiding the problem is of no help in solving the problem! Please try to reproduce the "MPREXE caused an invalid page fault in module KERNELEX.DLL" problem with first release.0 and then release.4. The latter should detect the NULL pointer before the crash and display first a "storage #x is NULL" messagebox and then a deep stack dump messagebox. I need to know the value of #x and the contents of the stack dump (should be on the clipboard).

What is the exact MB and what bios setup options are available?

Release.4.7z 4.5.2015.4_source_delta.7z KernelEx v4.5.2015.4 by jumper2015-01-14Resources: simplified version.h-based update methodPrep: FORWARD_TO support, better ordinal support, output cosmeticsKexcrt: debug messages upon NULL pointer to StrCpy()Kexbasen new: Gdi32:GdiAlphaBlend=>Msimg32:AlphaBlend Gdi32:GdiGradientFill=>Msimg32:GradientFill Gdi32:GdiTransparentBlt=>Msimg32:TransparentBltKexbases stubs: Kernel32:HeapQueryInformation=z5e ;Msvcr100 Ntdll:vDbgPrintExWithPrefix=t5 ;ReactOS 2014-06-11Now working without Kexstubs: Qupzilla 1.1.5 Slimboat 1.1.50 (with QtWebKit4 4.7.4 from Qupzilla 1.1.5)

The plan is to keep a basic set of auxiliary DLLs with minimal functionality for inclusion with KernelEx. Then have larger and more functional versionals of each that can be downloaded and installed individually as plug-ins. On my system, I am currently using four ReactOS (6-11-2014) DLLs as plug-ins. I put them in a KernelEx\ROS subfolder so my Ktree entries look like this KernelEx_KnownDLLs.reg file: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs] "MSIMG32"="MSIMG32.DLL" "PDH"="PDH.DLL" "PSAPI"="PSAPI.DLL" "USERENV"="USERENV.DLL" "UXTHEME"="ROS\\UXTHEME.DLL" "WINTRUST"="ROS\\WINTRUST.DLL" "WLDAP32"="ROS\\WLDAP32.DLL" "WTSAPI32"="ROS\\WTSAPI32.DLL"

KernelEx Auxiliary DLL Updates psapi3b.7zuxtheme.7zuxtheme423.7z Update packages include DLL and complete source code. DLL API Counts Stock = KernelEx 4.5.2 Msimg32: Stock (5) WinXP (5) Pdh: Stock (71) WinXP (158) Psapi: Stock (17) WinXP (24) psapi3b.7z (27) Userenv: Stock (16) WinXP (110) Uxtheme: Stock (48) WinXP (95) uxtheme.7z (95) Uxtheme423.7z (124) Wtsapi32: Stock (20) WinXP (35) ROS.41 (44) --- Stock --- Msimg32 (5 of 5): 4.5.2 Pdh (71 of 158): 4.5.2 Psapi (17/27 of 24): 4.5.2/psapi3b.7z Userenv (16 of 110): 4.5.2 Uxtheme (48/95/124 of 124): 4.5.2/uxtheme.7z/Uxtheme423 Wtsapi32 (20 of 35): 4.5.2

Good feedback, everyone. As for a standard test suite, it's better that we don't have one. At each update I'll try to mention at least one app that is helped (less reliance on Kexstubs). As of 4.5.2015.3, Slimboat 1.1.50 (with QtWebKit4.dll from Qupzilla 1.1.5) no longer outputs to Kexstubs.log. K-meleon74_31 now just has one output. Note: outputs to Kexstubs.log are stubs that are actually called, not all of dependencies needed to load an app. Drugwash, I commented out the last two variables because they are not being used. Each file should be versioned independently and have its own build comments, however, it is much easier to update one file than three (or four: Kernelex, Kexbasen, Kexbases, Sheet?). I'll put separate version and comment definitions for each in the next version.h. I don't do batch builds and haven't (knowingly) changed the 4.5.2 workspace file. I also haven't seen any of your source (Cloudme is very difficult to access from Win98se--please provide direct links to files). Do whatever works best for you. The crash we are seeing is definitely in Kernelex.dll, not kexbasen. With the null pointer check now added to strcmp, it has just been defered to strcpy. The affects of Kexstubs on the crash indicate a problem loading the API tables. The problem appears to be in the C++ configuration code, possibly in MAP or XTREE. What I need is a much deeper stack dump, or better yet, an actual stack trace. I'll add debug info to the next build of Kernelex and also a popup with a deeper stack dump at the first null pointer detection in strcmp. Any feedback from Release.0.7z? I really need to hear from the ten who downloaded it. Doug, thanks for testing with SP3. The "Update DLL!" messageboxes are from Kexstubs (should be identified in the title bar). As MiKl noted, if you have already updated MSCVRT you don't need those definitions anymore.

The Kext:DIY topic has dozens of success stories. No more general discussion here, please.

Changelog: KernelEx v4.5.2015.3 by jumper2015-01-06Resources: updated all product and file versions and resource languageskexcrt: fixed level3 warnings, 64-bit returns no longer truncated to 32-bitsKexbasen: DLL delay loading standardized for simplicity and robustnessKexbasen: added Oleaut32 templateKexbasen stubs: Oleaut32:442/RegisterTypeLibForUser, 443/UnRegisterTypeLibForUserKexbases fixes: Kernel32:VirtualProtect - dont let GCC apps disable write accessKexbases stubs: Shell32:727/SHGetImageList, Kernel32:*ActCtx*, Kernel32:*SList*

>GCC fix and Shell32 ordinal 727 are very cool to have directly in kernelex Shell32:727 was requested in the DIY topic! >Since the only change in kexbasen is the addition of oleaut32 functions, it's safe to think the problem is right there. Did you try version x.0? It doesn't have the oleaut32 functions, just a version update. For Kexbasen 4.5.2015.3, kexcrt has a tweak in strcpy to prevent the crash but the actual problem is still undetermined. It feels like an uninitialized variable somewhere that is usually zero but could be any value depending on what gets loaded where. I'm still working on it--more stack traces are welcome. >Well, how's the Time market, any changes in price? Just 16 bits for 54 hours!

4.5.2015.3 dlls+maps 4.5.2015.3 diff source Changelog: KernelEx v4.5.2015.3 by jumper2015-01-06Resources: updated all product and file versions and resource languageskexcrt: fixed level3 warnings, 64-bit returns no longer truncated to 32-bitsKexbasen: DLL delay loading standardized for simplicity and robustnessKexbasen: added Oleaut32 templateKexbasen stubs: Oleaut32:442/RegisterTypeLibForUser, 443/UnRegisterTypeLibForUserKexbases fixes: Kernel32:VirtualProtect - dont let GCC apps disable write accessKexbases stubs: Shell32:727/SHGetImageList, Kernel32:*ActCtx*, Kernel32:*SList*

Theoretically we could figure out what driver was loaded at 60E and that would identify the component we should be looking at. In practice, if I get a blue screen at boot I just undo any BIOS or hardware changes I just made or restore the previous registry if I was tweaking Windows. If the memory tests okay, boot with logging and compare the log to a known good one (if available).

I extracted the DLLs from the original package last night and they worked fine in SE. The Master branch already is using version 4.5.3, so I've settled on 4.5.2015. I'll post updates in about sixty hours. Edit: just buying time....

Good sleuthing, Drugwash. And double-thanks for the quick build on short notice! /O1 is for size /O2 is for speed I've always found /O1 to be the better choice as I can #pragma or _asm individual functions as needed. I entered "jumper" in the special build field so.... From Winver.h: /* ----- VS_VERSION.dwFileFlags ----- */#define VS_FF_DEBUG 0x00000001L#define VS_FF_PRERELEASE 0x00000002L#define VS_FF_PATCHED 0x00000004L#define VS_FF_PRIVATEBUILD 0x00000008L#define VS_FF_INFOINFERRED 0x00000010L#define VS_FF_SPECIALBUILD 0x00000020LAnd also this typo: DWORD dwFileFlags; /* e.g. VFF_DEBUG | VFF_PRERELEASE */ Generate Browse Info (/FR) Exclude Local Variables (/Fr) intrinsic(_BitScanForward) isn't available in VC5/6 (maybe later?). But in jemalloc.c, BitScanForward isn't currently being called. So move the pragma line to here: #if 0#pragma intrinsic(_BitScanForward) if (_BitScanForward(&i, x) != 0)Back in May, I fixed psapi.c to work with ProcWin and added stubs for _all_ new functions. Last week I also updated uxtheme for all new functions (with correct ordinals). I'll release these for code review in a new topic ("KernelEx aux updates"?) asap. @loblo and DougB: I thank you both for the feedback. Kexbasen (7d00xxxx) didn't show up in loblo's original stack trace, so now I'll take a closer look at it. Odd that removing Kstub822 should affect anything.... Here's my very first build that has original setting with just the resources touched:

@MiKl: I didn't expect my small changes to affect any apps already running. I haven't tested SumatraPDF since 2.3.2, but will do so soon. @loblo: I don't have a WinME system to test on, so I'll need a bit of help. Please try the x.1 DLLs individually. I somehow failed to save the MAP files for this particular build, but the problem seems to be a NULL pointer passed to a kexcrt ANSI string copy routine. DumpPE (C.Turvey) and ProcWin (Japheth) were both able to disassemble Kernelex.dll for this analysis. @Drugwash: KernelEx trys to improve the user experience by fixing existing functions, rerouting (forwarding) calls from one module to another, and creating new functions by stubbing, faking, partially or fully implementing them--whatever it takes. Many NT calls have no meaning and are easily stubbed. Full implementations take much time to develop and test, and balloon both the memory footprint and install package! It's been just over three years now since the release of 4.5.2. If you could revisit the original build and then add just the GCC fix, it would be great to have a new release to kick off the new year. "warning C4013: 'strntoumax' undefined; assuming extern returning int" Increasing the compile warning level from 1 to 3 revealed that kexcrt wasn't properly prototyping the 64-bit strntoumax(), so in at least nine places the return value was truncated to 32-bits before being assigned to a 64-bit variable. I added prototypes and casts to fix 22 warnings. One more warning needs further study ("unary minus operator applied to unsigned type, result still unsigned"). I am standardizing a method for delay loading libraries and functions the combines the best of the several techniques currently in use. It's important to do this now as much new code will be using it. New release 4.5.12.2 -- Map files included this time! <<TBD: post source>>

In the apilibs source folder, we find subfolders for Kexbases and Kexbasen. To kexbases\Kernel32, I added VirtualProtect.c. This code has been tested via Kexstubs on my primary machine for six months: // Don't let GCC apps 'accidentally' disable write access: If desired access protection// is PAGE_READONLY and location is in PE image, request PAGE_READWRITE instead./* MAKE_EXPORT VirtualProtect_fix=VirtualProtect */BOOL WINAPI VirtualProtect_fix( LPVOID lpRegion, // address of region of committed page DWORD dwSize, // size of the region DWORD flNewProtect, // desired access protection PDWORD lpflOldProtect // address of variable to get old protection){ if (flNewProtect == PAGE_READONLY) { MEMORY_BASIC_INFORMATION mbi; if (VirtualQuery (lpRegion, &mbi, sizeof(mbi))) //find base if (VirtualQuery (mbi.AllocationBase, &mbi, sizeof(mbi))) //query base if (mbi.Protect & 0x66) //readable? if (*(WORD*)(mbi.AllocationBase) == 'ZM') //PE image? flNewProtect = PAGE_READWRITE; } return VirtualProtect (lpRegion, dwSize, flNewProtect, lpflOldProtect);}To kexbases\shell32, I added SHGetImageList.c which exports SHGetImageList both by name and ordinal: #define ERROR_CALL_NOT_IMPLEMENTED 120L/* MAKE_EXPORT SHGetImageList_stub=SHGetImageList *//* MAKE_EXPORT SHGetImageList_stub=ordinal727 */HRESULT WINAPI SHGetImageList_stub (int iImageList, REFIID riid, void **ppv){ return ERROR_CALL_NOT_IMPLEMENTED;}To Kexbasen, I added an Oleaut32 module with two function stubs exported both by name and by ordinal. I added them to the non-shared Kexbasen so they can be upgraded to delay-loaded forwards to (Un)RegisterTypeLib in the future. kexbasen\oleaut32\_oleaut32_apilist.c created kexbasen\oleaut32\_oleaut32_apilist.h created kexbasen\oleaut32\oleaut32.c #define ERROR_CALL_NOT_IMPLEMENTED 120L/* MAKE_EXPORT RegisterTypeLibForUser_stub=RegisterTypeLibForUser *//* MAKE_EXPORT RegisterTypeLibForUser_stub=ordinal442 */HRESULT WINAPI RegisterTypeLibForUser_stub ( ITypeLib *ptlib, OLECHAR *szFullPath, OLECHAR *szHelpDir ){ return ERROR_CALL_NOT_IMPLEMENTED;}/* MAKE_EXPORT UnRegisterTypeLibForUser_stub=UnRegisterTypeLibForUser *//* MAKE_EXPORT UnRegisterTypeLibForUser_stub=ordinal443 */HRESULT WINAPI UnRegisterTypeLibForUser_stub ( REFGUID libID, WORD wMajorVerNum, WORD wMinorVerNum, LCID lcid, SYSKIND syskind ){ return ERROR_CALL_NOT_IMPLEMENTED;}In apilibs\kexbasen, main.c and dirlist were updated to reflect the new oleaut32 modules.Full source diff package: K4521src.7z

KernelEx 4.5 Core Updates 4.5.2016.17 4.5.2016.16 4.5.2015.11 4.5.2015.10 4.5.2015.9 - source (full) 4.5.2015.8 4.5.2015.7 4.5.2015.5 - source (diff) 4.5.2015.4 dlls --- Extras --- ApiHook 4.5.2015.8 - Real-time API logger Kexports - API export lister for KernelEx DLL's ImportPatcher - View and edit dependencies . . . Dependency Walker 2.2.6000 TaskInfo2000 v2.1 ProcWin DumpPE How to install in Windows: backup existing Windows\KernelEx DLL files extract all files into one folder launch Update (or InstallDLLs) shortcut Reboot system! How to install in DOS: backup existing Windows\KernelEx DLL files extract DLL, EXE, and PDB files "Exit to DOS" out of Windows copy extracted files to Windows\KernelEx folder Reboot system! Changelogs: [see individual release posts] These updates are based on the source for the highly-tested KernelEx 4.5.2. Changes to the source will be presented in following posts. Changes will initially come from the 4.5.3 beta ("Master" branch), Kexstubs, and related projects. I did slip a few "wish-list" gifts into this first package just for Christmas: Kexbases.dll 4.5.12.1 has a Kernel32:VirtualProtect wrapper to fix the GCC problem and a Shell32:727 ordinal stub. Kexbasen.dll 4.5.12.1 has Oleaut32:442/RegisterTypeLibForUser and 443/UnRegisterTypeLibForUser ordinal/name stubs. Kernelex.dll 4.5.12.1 is a straight rebuild of 4.5.12.0 with just the version resource updated. My toolchain isn't 100% complete, so I have no plans for releasing a full, updated KernelEx package. Is anyone interested in doing this? Topics for discussion Versioning: Last official KernelEx product is 4.5.2, files 4.5.12. I'm currently using product 4.5.2015, files 4.5.2015.x. Updates installer: Currently using a batch file. Still taking suggestions for wininit.ini or better solution. API families TBD (additions welcome) My Kstub822.ini has lots of these definitions. Which need partial or full code rather than stubs? Ace Acl/Dacl/Sacl (Security) ActCtx AnsiString/OemString/UnicodeString Cred Fls Lsa MD5 SList Trace Any technical discussion concerning updates/changes to KernelEx API support or architecture are welcome. Please report all known issues and limitations in KernelEx 4.5.2 so we can addressed them. Known issues: API names must be stored in sorted order in memory plug-in limit is 4: std + kexbases + kexbasen + two more ApiConfigurations limit is 11 (0..10); higher numbers show but don't "stick" DLL must exist and be loaded for a new API to be added new API can't be added to DLL loaded via KernelEx\KnownDLLs no distinction between implicit(loader) and explicit(GetProcAddress) dynamic linking Psapi code problems An older version of this top post can be found at the Internet Archive Wayback Machine.

If the BIOS has an "Enable L1 cache" option, unchecking it will usually cripple performance!

>I did set a static IP address, but it didn't seem to improve the boot time much. Disable the network adapter in Device Manager. That should speed the network boot delay and you can reenable it on-the-fly in Device Manager when you need it. >What exactly is Windows doing when it "enumerates" devices? Synchronously loading each device driver one at a time, waiting for each to complete before loading the next. >booting in Safe Mode is slightly shorter Not everything is loaded. Safe Mode without networking should be even faster.

The internal CDDA filter (v6.4.0.2) in MPC6.4.9.1 is "2K/XP only" (tip text). Disable it in View>Options>Internal Filters when trying external filters.

Just put a copy of GdiPlus.dll in the Windows System folder. I use version 5.2.3790.136.

If you use DHCP to assign a dynamic IP address, your router must be up and running before Tcpip loads or you get a long delay. Assign a static address or disable the adapter if the network is not always available at boot.

Create a boot log and check it with BootLogAnalyzer bla.exe. Networking is a likely suspect.

Another idea: C:\>attrib/s R:\test.cmd | find/i "\oem\runonc~1\test.cmd" A HR TEST.CMD R:\OEM\RUNONC~1\test.cmd A TEST.CMD R:\Z\OEM\RUNONC~1\test.cmd