jumper

According to this link: Google translates the error message to: Palemoon caused an error by a invalid page in module KERNEL32.DLL at 01ef: bff6a4e9 ... Stack dump: 00650050 00000000 004c000c 004c0000 004c985c 00000040 00000000 00000b19 000004ca 0095e748 bff6a6b1 004c0000 004c985c 00000018 00000040 00000013 Subtracting bff60000 from bff6a4e9 and bff6a6b1 and looking up those addresses for Kernel32.dll in Dependency Walker indicates that the error happened in a support function called by IsBadWritePtr. Apps usually load at 00400000, so all those 0040xxxx values on the stack are probably data pointers within Palemoon.

No. "reverse the direction" refers to another method unrelated to fwd. Yes! I finally posted fwd.02 that I was working on last month. I'm not sure what state it was left in, but it has better logging and patching.

What were the error details and Kernel32.dll version? If we cross-reference the instruction address/EIP value with Kernel32.dll function export addresses using a PE viewer, we should be able to determine what function was running. (In the case of your previous post, the Stack dump should reveal what module--and possibly function--might have jumped into unknown memory.) If you have VC++ installed, click on [Debug] in the error dialog to launch it. Then View->Debug Windows->Call Stack to see the calling sequence. I'll try to write a JIT debugger (based on FineSSE) that looks up the call sequence (and maybe offers a live recovery attempt!).

Thanks, bpalone! Indeed, blackwingcat includes code in commonfix.h for the following nine VC++2010 functions that is more complete than KernelEx 4.5.1: EncodePointer DecodePointer FindActCtxSectionStringA FindActCtxSectionStringW HeapQueryInformation HeapSetInformation InitializeCriticalSectionAndSpinCount IsDebuggerPresent IsProcessorFeaturePresent It been awhile since I've browsed in the Win 2000 section; I also found interesting tools from WildBill (PE Tool) and BlackWingCat (PEMaker) and DLL collections from tomasz86 to try out.

I've updated the list with some new project/discussion links. We now have a working solution to printing from apps that call PrintDlgExA or PrintDlgExW.

ImportPatcher lets us replace any DLL or function name string with any other string that will fit. It then checks to see if those DLLs and functions exist, but doesn't do any return value or type checking--that is up to the user to research (or guess!) which stub is the best to use. Matching the number of parameters is important for preventing stack corruption. Return value is important because it can signify success or failure; the actual type doesn't matter if the raw value is correct. Ideally, the user would research each function to be replaced at MSDN before selecting (or writing) a stub with the best characteristics. I think guestimation and trial-and-error are the methods that often get used instead.

Thanks, Drugwash. Good work. I rate it two thumbs up: I see the update now alphabetizes and can also sort by parameter count. Also ~450 duplicates have been removed from the list! I've added a link to your post (#80) in the header of post #1, and also a mention in the topic subtitle.

The problem turned out to be that KernelEx is needed for GetOpenFileNameW, but undesired for PrintDlgExW (and vice versa for ComDlgEx) . KernelEx also can't process ComDlg32 functions unless they are imported (not export-forwarded) from a DLL named ComDlg32.dll So the solution was two-fold: switch from export-forwarding to wrappers of imported functions use dependency order App->ComDlgEx->ComDlg32 Using the previous test versions, KernelEx processing was either fully enabled or fully disabled--meaning it allowed GetOpenFileNameW to work but returned an error for PrintDlgExW, or the new PrintDlgExW worked but GetOpenFileNameW was not patched to work. This affected apps that use the Wide functions: SumatraPDF 1.8, 1.9, and apparently FireFox 3. Apps (like SumatraPDF 0.9) that use the Ansi functions don't need a KernelEx patch for GetOpenFileNameA, so could print and open files under some install methods (when redirected). [if requested, I'll expand the above to explain in more detail why each function worked (or didn't) on each app for each method.] Because KernelEx 4.5.1 does some processing of most of the functions in ComDlg32, I will next try to break out all of that code into a stand-alone DLL into which I can add the new PrintDlgEx code. If successful, this new DLL would be installed using an easier Method 2 (without the renaming or copying). It would also be an example of how KernelEx can be extended without recompiling the full core package.

Plan E: ComDlgEx.7z Like the original plan A, but with wrappers for all functions. Works for opening and saving files as well as printing in SumatraPDF 0.9 and 1.9 Requires no '00' dll... ...however requires ImportPatcher (or hex editor) to patch apps. Installation Method 4: put ComDlgEx.dll in <system> folder (for multiple apps) app folder (for single or portable app) [*] use hex editor or ImportPatcher on app to change import dependency: [DLL replacements] COMDLG32.DLL=ComDlgEx.dll Build environment: MS DevStudio 97 / VC++ 5.0 sp3 / Win98sePlease try others! ComDlgEx.c: ComDlgEx.def: Ssync_ANSI_UNICODE_Struct_For_WOW has been removed.

I have two older cameras that use TWAIN. I have two newer cameras that are Mass Storage Devices. I can load pix/vids from the older cameras into IrfanView using TWAIN, or transfer the files using the bundled (custom) apps. I don't use and hadn't heard of WIA before this thread. A worthy topic and good discussion, however!

All original functions are mapped through to ComDlg00.dll. Nothing should be broken--the open and save dialogs are working for me using methods 1b and 2[edit] in Notepad and SumatraPDF 0.9 (with Kex). In SumatraPDF 1.9 with Kex, however, the open dialog fails to appear. I have an idea of how to fix this that I'll try in the morning[/edit]. If an app is linked to this function, it will load instead of reporting a link error. If the app calls this function and checks the error code using GetLastError, it will see that the function is not actually implemented. The function is probably for NT's internal use in 16-bit "Windows on Windows" emulation. It is unlikely to ever be called in Win9x.

This sounds like a project wish to me: My experience with FAT32 is that apps escape any characters that would be illegal: %3F %2A %2F .... Would hooking the system file APIs to un/escape name strings work? Would unicode file names be a problem (or a solution)? What about path length limits? The problems I run into here usually concern command-line parameter passing to (my) apps or DOS batch files.

MSVCRT.DLL version 6.10.9848.0 contains _fstat64. So also do MSVCR70.DLL 7.00.9981.0 and MSVCR71.DLL 7.10.7031.4 (for anyone using them as a MSVCRT.DLL update). All are available in 98 SE SP 3.0.

Is the activity light on the pen drive on during the delay? Something is probably writing to the drive, causing the delay. A faster pen drive should have less delay. ResourceMeter can show you how much (and how fast) data is being written to the drive. Use a process viewer to determine what program is most active during the delay. If it is a virus scanner, disable scanning on that drive letter. You may also be able to enable (or disable) caching of removable drives to improve performance: ->Control Panel->System->Performance->File System->Removable Disk

After two months of delays , ImportPatcher.35 is finally posted. I added CheckSum zeroing so Dependency Walker would stop complaining about the invalid checksums.

Two better versions to try: ComDlgEx.7z ComDlgEx.dll - supports all three new functions: PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA PrintDlgExW - uses PRINTDLGW struct to call PrintDlgW Ssync_ANSI_UNICODE_Struct_For_WOW - stub: SetLastError(ERROR_CALL_NOT_IMPLEMENTED) [*]ComDlgEx2.dll - as before, but support for both flavors PrintDlgExA - uses PRINTDLGA struct to call PrintDlgA PrintDlgExW - redirects to PrintDlgExA Recommended installation method: 1b.

If win.com runs from autoexec.bat, try adding: win.com @cd\ @dir /b/w > nul @cd\windows or create a win.bat with the above code. For automated windows exit and restart, perhaps you could put reboot.exe in the root directory and have windows run it from there.

A Google search for "SeaMonkey +PrintDlgW" yields antivirus scans showing that SeaMonkey 1.9 and 5.0 use PrintDlgW. And Firefox 9.0 too! Method 2 seems to cause Kex to bypass its internal ComDlg32 support. Methods 1 and 3 should be complementary to Kex--use one of them with the current ComDlg32 update to prevent apps that need PrintDlgExW from failing to load. This is excellent feedback. It made me realize that if I add a stub for PrintDlgExW that returns success instead of failure (as Kex does), the default parameters will be used unchanged and something might print for those apps (like SumatraPDF 1.9) that need PrintDlgExW!

This update currently only addresses the missing PrintDlgExA function in ComDlg32.dll. Try testing with SumatraPDF 0.9 instead. With Seamonkey loaded, try deleting <system>\ComDlg00.dll. If you get a file-in-use error, that will confirm that the new ComDlg32.dll is correctly installed and in use. Does Seamonkey display a Print Dialog at all? If not, Seamonkey must not be calling PrintDlgExA and has another issue not addressed by this update. Please search the Seamonkey folder for files with text "PrintDlgExA". If none are found, Seamonkey cannot be used to test this update. Instead, use ImportPatcher to test Seamonkey for missing imports and post results here. Thanks! Tonight I will try to implement PrintDlgExW and update the update.

Three ways to install the ComDlg32.dll update: In <system> folder (affects all applications including OS): rename to ComDlgEx.dll and place in <system> folder do one of the following: DOS method exit to DOS and cd to <system> folder rename COMDLG32.DLL to COMDLG00.DLL rename COMDLGEX.DLL to COMDLG32.DLL KnownDLLs method: copy <system>\ComDlg32.dll to <system>\ComDlg00.dll merge into registry: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "COMDLG32"="ComDlgEx.DLL" In <windows>\KernelEx folder (affects only KernelEx-enabled applications): place in <windows>\KernelEx folder copy <system>\ComDlg32.dll to <system>\ComDlg00.dll merge into registry: REGEDIT4 [HKEY_LOCAL_MACHINE\Software\KernelEx\KnownDLLs] "COMDLG32"="ComDlg32.dll" In specific application/DLL folders (affects only those EXEs/DLLs): place in folder of EXE or DLL that references PrintDlgExA copy <system>\ComDlg32.dll to <system>\ComDlg00.dll remove any global redirection from registry: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager\KnownDLLs] "COMDLG32"=- Note: To modify registry, save boxed text as new.reg, right-click and select 'Merge'; or use RegEdit.

If you also have a physical COM2 port, perhaps you can just swap them: In BIOS: swap COM1 and COM2 addresses and IRQ values In Windows: in System Properties->Device Manager->Resources unselect "Use automatic settings" for both COM1 and COM2 swap their Basic configurations. In Hardware: if you suspect a damaged connector, swap connector headers In DOS this might work: mode com1=com2

Installation clarification using SeaMonkey as an example: Q) Where in the SeaMonkey folder should I place the dll? I find dll's in almost every folder there. A) Place a copy of my ComDlg32.dll in the folder containing SeaMonkey.exe. Also, search for text "PrintDlgEx" in SeaMonkey's top folder using Find. Place a copy in the folder of each file that contains a reference to "PrintDlgEx". Q) Should I rename comdlg32.dll to comdlg00.dll and NOT replace the original windows one with your dll? So, Windows does not have this file at all? A) Copy (do not Rename) the original ComDlg32.dll: Right-click on the original ComDlg32.dll, drag until [+] appears and release, then select "Copy Here". Rename the new copy "ComDlg00.dll". The original ComDlg32.dll remains for all other programs to continue using.

ImportPatcher status update: IP.35 needed several rewrites before it became stable, but now the PE header parsing code is more robust than ever. It detects UPX-compressed files and doesn't attempt to parse the invalid delay-import entries. Three types of dependencies are still not supported: import forwarders, export forwarders, and dynamic delay-loads. I've been learning a lot about export forwarders lately and if import forwarders work the same way, both of these should be relatively simple to implement. Dependency Walker uses a profiling method to find dynamic delay-loads. A future IP could add a 'Profile' option to the summary MessageBox if there is a GetProcAddress dependency. If 'Profile' is selected, it would hook GetProcAddress and launch the app. Another possibility would be to search the code section for calls to GetProcAddress and grab the addresses of the function name strings. Search again for LoadLibrary and grab those DLL name strings, then cross reference functions and DLLs.

Boot Up Floppy Seek can be Disabled for a quieter boot. Memory Hole at 15M-16M can be Disabled. Auto Detect DIMM/PCI Clk should probably be Enabled for stability until you're ready to start tweaking. Spread Spectrum can be Enabled to reduce radio and television interference. The -5v supply is reading: -61.93v

Working solution: ComDlg32.7z Place ComDlg32.dll in app folder. In <winsysdir>, copy original COMDLG32.DLL to COMDLG00.DLL. Remove any COMDLG32 redirections in KnownDLLs. Should print to printer. Print to file not implemented yet in SumatraPDF 0.9. PrintDlgExA.c source: