jumper

The second is easy: stretch the wallpaper in Irfanview, etc., and resave. For the first you might try using autoruns to find and disable the backup process. Or try deleting the *.da0 files and creating folders with the same names.

GetUserDefaultUILanguage is already in Kexbases. I had similar results with SM2.32, but no crashes. Definitely a work in progress.

ImportPatcher.40.7z ImportPatcher.40 Interactive gui with drag and dropCheckboxes: [_] Start dependency search in local folder [_] Test by loading (KernelEx) [_] Process delay imports [_] Walk dependencies [_] Unbind broken bindings [_] Show APIs for missing DLLs [_] Target Win9x (Subsystem version 4.0) [_] Save settings as .ini file [_] Create detailed .log file Buttons:[ Analyze only ] [ Patch ] [ Cancel ] Large editable results box Still TBD:- ordinal support - local walk - sub/folder processing - unUPX

SeaMonkey 2.32 loads with the following two stubs: [shell32.dll] SHEnumerateUnreadMailAccountsW=r0x80004001s4 ;SM2.32 SHSetUnreadMailCountW=r0x80004001s3 ;SM2.32 Using it now to post this reply! [Edit]And now editing the post in FF2 to get the line breaks to appear[/edit]

R8 will have api logging so we can begin tracking down many of these pesky issues. I'm using the apihook code with some improvements to make it easy to use. @Drugwash -- use threading settings from 4.5.2 if you need to. We are ignoring standard libraries and providing our own crt code. The .text warnings are because I .merged sections and used dosstub.exe for size in VC5 on those. Jusr remove the .merge and .stub linker options.

I use Media Player. QuickTime 4 also works well.

Yes, FF2..20 supports frames/iframes. Check browser.frames.enabled in about:config and any content-blocking plugins you might have. If you right-click inside the frame, you should see "This Frame >" in the context menu. Try some of the submenu options.

In the stack dump, I'm seeing way too many duplicate return addresses in Kernel32 (bff6....) and Kexbases (bfa4....). Looks like a stack leak is happening. The crash is in module FOXITREADER.EXE, so I'll need to get that to have any hope in determining what lead up to the crash. The last reference to Kexbases is bfa4d24b; what version are you using?

Release.7.7z KernelEx v4.5.2015.7 by jumper2015-01-22Kexbases bugfix: Kernel32:CreateProcessA (fix)Good new: all crashes are in KEXBASES.DLL at xxxx:bfa56000 in the CreateProcessA code I merged from 4.5.3beta. I've rewritten the fix including removing the offending line of code.

I'll repost my original #74 below. Original post #75 was Release 6 and changelog. I'll skip reposting this one. Thanks for the detailed reports. I'll do some debugging, then probably just revert to 5. I'll be more careful in using 4.5.3beta code! @MiKl - Are the Thunderbird 12.x and SeaMonkey 8 and 9 hangs a regression or progress compaired to 4.5.2 and recent updates? [answered!] @loblo - You may remember from the Kexstubs discussion last year that we were unable to find a working definition for FindActCtxSectionStringW; its mere presence caused some apps to crash. ReactOS' Ole32.dll needs it, however, and so may some other apps. So I've exported it as FindActCtxSectionStrin_W so ImportPatcher can easily mod a file into working. FindActCtxSectionGuid is not currently known to be needed and might also be dangerous, so I've treated it the same way. @tErmY - Thanks for testing. This is a BIG deal, however--regressions are not good. Can I correctly assume that FlashBlock 1.5.14.2 worked with v.4 and just not v.5? Please define "seems to have broken" and be very specific! If you are also using Kexstubs, please note the order of your "contents=" line in core.ini (mine reads "contents=std,Kstub822,kexbases,kexbasen") @Drugwash - I plan to do a cumulative delta source package at release 10. Hopefully you will be able to to build a full release for us at that time. Until then, don't feel obligated to manually merge and build every version. Maybe TmEE can help us with hosting or we can open a SourceForge account.

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: