Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

ImportPatcher - Find and fix dependency problems

- - - - - IP.38_(3/29/2013) IP.39_(7/06/2013)

  • Please log in to reply
128 replies to this topic

#1
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

ImportPatcher
Enable a new executable to load with old DLLs or on an older OS.

latest beta: Attached File  ImportPatcher.38.7z   4.15KB   24 downloads
preview alpha: Attached File  ImportPatcher.39.7z   4.6KB   19 downloads
debugging DLL: Attached File  IPstub.zip   2.49KB   98 downloads
Drugwash's API Parameter Count v1.0.1.0



New in Attached File  ImportPatcher.38.7z   4.15KB   24 downloads:
  • March 29, 2013
  • Delay-load processing made optional
  • Added file and data alignment checking
  • Ordinal import fields reversed in log (to match strings)

New in Attached File  ImportPatcher.39.7z   4.6KB   19 downloads:
  • July 6, 2013
  • Expanded first MessageBox into fuller DialogBox
  • Added export forward patching

New in Attached File  IPstub.zip   2.49KB   98 downloads:
Features:
  • Analyzes a program's OS subsystem and Import requirements
  • Walks (recurses through) all dependencies (optional)
  • Creates #.log file with detailed results
  • Creates #.ini file for controlling patching step
  • Patches OS subsystem if needed
  • Substitutes for any import modules and functions, missing or not
  • Patches hints for better performance (optional)
    Hint support disabled pending design review
  • Supports all Portable Executable (PE) files (apps, dll's, ...)

Works in two passes:
  • Invoke once to Analyze, then Edit the #.ini file
  • Retry at prompt (or invoke again) to Patch

Suggested usage:
  • Create a shortcut to ImportPatcher in your Windows SendTo folder
  • Send files to it using the right-click context menu.

Notes:
  • All file patching is done on copies.
  • Filenames containing '=' are incompatible with the use of an .ini file. Please rename.
  • If module MSVC*#*.DLL is reported missing, try replacing it with 'MSVC*71*.DLL.

History:
Spoiler

Edited by jumper, 13 February 2014 - 03:47 PM.

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs


How to remove advertisement from MSFN

#2
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag
This is one very cool tool which makes it so much easier and faster for replacing functions than using an hex editor.

:thumbup

#3
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

...I've just tried the Import Patcher on the "signtool.exe" utility from http://www.microsoft...ls.aspx?id=8442 (Microsoft Windows SDK for Windows 7 and .NET Framework 4). Image file = GRMSDK_EN_DVD.iso, Path = \Setup\WinSDKTools\cab1.cab, Extract file = WinSDK_signtool_exe_B2E1011D_2F14_488D_A056_C5BD55106409_x86.

Executing 'signtool.exe' by itself (with KernelEx 4.5.2) produces the error :

The SIGNTOOL.EXE file is
linked to missing export MSVCRT.DLL:__uncaught_exception.

Executing with Import Patcher gives a bunch of "Importing from module ..." messages, but not the above message. It also produces a file "signtoo#.exe" which has patches but seems to behave the same as "signtool.exe".

In addition, a log file is produced, from which the following is an extract :

    Importing from module: 'msvcrt.dll'
        __wgetmainargs: 225 != 142 #
        _cexit: 276 != 173 #
        _exit: 354 != 215 #
        _XcptFilter: 106 != 75 #
        exit: 1167 != 607 #
        _initterm: 469 != 282 #
        _amsg_exit: 257 != 162 #
        fgetpos: 1175 != 615 #
        __p__commode: 185 != 109 #
        __p__fmode: 190 != 114 #
        __set_app_type: 210 != 132 #
        ??1type_info@@UAE@XZ: 17 != 14 #
        msvcrt.dll: __uncaught_exception (db) * No match
        memmove: 1260 != 686 #
        _unlock: 934 != 495 #
        __dllonexit: 141 != 88 #
        _lock: 578 != 329 #
        _onexit: 747 != 403 #
        ?terminate@@YAXXZ: 55 != 48 #
        _controlfp: 295 != 186 #
        isleadbyte: 1218 != 651 #
        isupper: 1223 != 656 #
        _itoa: 561 != 319 #
        islower: 1219 != 652 #
        __badioinfo: 133 != 84 #
        __pioinfo: 207 != 130 #
        _fileno: 367 != 226 #
        _lseeki64: 587 != 337 #
        _write: 1096 != 555 #
        _isatty: 478 != 287 #
        ??0exception@@QAE@ABQBD@Z: 9 != 7 #
        ?what@exception@@UBEPBDXZ: 57 != 50 #
        ??1exception@@UAE@XZ: 16 != 13 #
        fwrite: 1201 != 636 #
        setvbuf: 1287 != 708 #
        fflush: 1173 != 613 #
        ungetc: 1341 != 749 #
        fputc: 1185 != 623 #
        fgetc: 1174 != 614 #
        malloc: 1246 != 679 #
        _callnewh: 274 != 172 #
        setlocale: 1286 != 707 #
        msvcrt.dll: ___lc_handle_func (7f) * No match
        msvcrt.dll: ___lc_codepage_func (7d) * No match
        msvcrt.dll: ___mb_cur_max_func (80) * No match
        abort: 1142 != 586 #
        ungetwc: 1342 != 750 #
        msvcrt.dll: __pctype_func (ce) * No match
        __crtLCMapStringA: 138 != 87 #
        msvcrt.dll: __iob_func (93) * No match
        __mb_cur_max: 176 != 100 #
        msvcrt.dll: __crtLCMapStringW (8b) * No match
        wctomb: 1390 != 778 #

Now two questions come to mind :

1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher?

2. Should the "signtoo#.exe" application run OK (not exhibit the same missing import/export message)?

Joe.

 

The SIGNTOOL.EXE file islinked to missing export MSVCRT.DLL:__uncaught_exception.

Looks like MS has added a new function to a venerable support file. Substituting another function or stub for '__uncaught_exception' might not be acceptable to the calling app. If not, try locating a version of MSVCRT.DLL that includes this function.

Executing with Import Patcher gives a bunch of "Importing from module ..." messages, but not the above message. It also produces a file "signtoo#.exe" which has patches but seems to behave the same as "signtool.exe".

ImportPatcher.27 was my last internal build back on Nov 10, 2011, before development took a break. Those are debug messages--I never expected to release that build as a sneak-preview.

IP.27 patches the OS version and creates a dependency log that is somewhat readable. The resulting #.exe file will only be loadable if the OS version was the only load error. Also, a *#.* copy of every file that is walked is created, including system DLLs (only useful if you're trying to fragment your HDD!).

Try again with IP.28; or better yet, with IP.29 later tonight.

1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher?

IP.28 reads parameters from an .ini file that can be edited between passes.

2. Should the "signtoo#.exe" application run OK (not exhibit the same missing import/export message)?

That is the goal. If you supply valid replacement functions, the patched copy should get past the system loader.

Edited by jumper, 26 December 2011 - 09:39 PM.

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#4
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

Joe, it's the ini file that matters the most. You should find in it a section per dependency listing the missing functions as follows:

missingfunction=Y

Then you just need to replace the Y by whatever function you want to replace it and rerun the tool which will patch accordingly. (If you want no change for a missing function which is best for what KernelEx already caters for then replace Y by the missing function such as: missingfunction=missingfunction).

:yes: Good idea, loblo! Upcoming beta29 will now do that for us:

[KERNEL32.dll]
DecodePointer=DecodePointer
EncodePointer=EncodePointer

[Missing modules]
MSVCR100.dll=MSVCR100.dll
It also adds a similar option for missing modules.

For example, this works quite well:

[Missing modules]
MSVCR100.dll=MSVCR90.dll

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#5
slhk

slhk

    Junior

  • Member
  • Pip
  • 68 posts
  • Joined 03-August 08
Hi jumper

Your program is very useful, but it is not easy for newbie to understand how to use it

Could you provide a step-by-step successful example?

Many thanks

#6
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
Sorry for the delay, slhk. I've been looking for and finally found a good example.

Back on 5/5/2003, I installed Microsoft Active Accessibility which updated COMCTL32.DLL from version 5.00.2614.3500 to 5.00.2614.3600.

Version 5.00.2614.3500 is part of IE5.0 and imports bound links from other IE5.0 DLLs.
Version 5.00.2614.3600 is part of IE5.0.1 and is bound to other DLLs that didn't get updated, causing loading delays.

I copied v3500 to my temp folder and named it COMCTL32aa.DLL.
I copied v3600 to my temp folder and named it COMCTL32bb.DLL.
I analyzed each of these files in ImportPatcher.29 (by dragging them to a shortcut on my desktop).

The .ini file for v3500 shows an empty list under "[Need patching? (do not edit)]" -- this indicates no errors found:

COMCTL32a#.ini
[ImportPatcher.29 - Intructions]
;Edit parameters and replacement strings and run ImportPatcher again. <=

[Parameters]
Mode: (A)nalyze or (P)atch=A
Walk dependencies=N
Link to copies=Y
Fix function hints=Y

[Need patching? (do not edit)]
The .log file for v3500 shows good binds with KERNEL32.dll and ADVAPI32.dll, but bad binds with GDI32.dll and USER32.dll. This indicates GDI32.dll and USER32.dll were build to match a different KERNEL32.dll and also need to be fixed.

COMCTL32a#.log
Spoiler

The .ini file for v3600 shows "R:\COMCTL32bb.DLL=Y (function hint)" under "[Need patching? (do not edit)]" -- this indicates that some ordinal link hints need fixing:

COMCTL32b#.ini
[ImportPatcher.29 - Intructions]
;Edit parameters and replacement strings and run ImportPatcher again. <=

[Parameters]
Mode: (A)nalyze or (P)atch=A
Walk dependencies=N
Link to copies=N
Fix function hints=Y

[Need patching? (do not edit)]
R:\COMCTL32bb.DLL=Y (function hint)
I edited the Mode parameter to read "Mode: (A)nalyze or (P)atch=P" and reprocessed in ImportPatcher.
The .log file then confirmed lots of patched mismatched function ordinal hints:

COMCTL32b#.log
Spoiler

To confirm the problems had been fixed, I renamed to COMCTL32b#.DLL file to COMCTL32.DLL and reanalyzed:

COMCTL3#.ini
[ImportPatcher.29 - Intructions]
;Edit parameters and replacement strings and run ImportPatcher again. <=

[Parameters]
Mode: (A)nalyze or (P)atch=A
Walk dependencies=N
Link to copies=Y
Fix function hints=Y

[Need patching? (do not edit)]
Nothing needs patching and:

COMCTL3#.log
Spoiler

all ordinal hints match actual function ordinals!

The last step was to backup the original v3600 in Windows\System and replace it with the newly patched COMCTL32.DLL.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#7
slhk

slhk

    Junior

  • Member
  • Pip
  • 68 posts
  • Joined 03-August 08
jumper, thanks for the detailed explanation. All is clear now :)

#8
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

This is one very cool tool which makes it so much easier and faster for replacing functions than using an hex editor.

:thumbup

It's quite amazing, really! :thumbup

Looks like MS has added a new function to a venerable support file. Substituting another function or stub for '__uncaught_exception' might {not} be acceptable to the calling app. If not, try locating a version of MSVCRT.DLL that includes this function.

Well, I found a version "7.0.6002.18005 (lh_sp2rtm.090410-1830)" on a Vista machine, dated 2009/4/11. However, although this version only reported "[Need patching? ... msvcrt.dll=Y (OS subsystem)" in ImportPatcher (with 'Walk dependencies=N'), after being patched for the OS subsystem, it looked like a descent into DLL dependency hell.

Also, a *#.* copy of every file that is walked is created, including system DLLs (only useful if you're trying to fragment your HDD!).

Does this relate to the "Link to copies=Y/N" option in the INI file? Would this also require "Walk dependencies=Y"?

1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher?

IP.28 reads parameters from an .ini file that can be edited between passes.

I think that ImportPatcher.27 gave the impression that it would load and execute a file, while satisfying missing dependencies. Since that doesn't seem to be the case, my earlier question was null and void.

Joe.

#9
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
Since writing the COMCTL32.DLL example the other day, the patched COMCTL32.DLL has been running on my system with no problems.

>It's quite amazing, really!

Thanks, but it's really just an exercise in learning how to parse the various header structures in the Portable Executable file format. Documentation and guides are hard to find and incomplete, but I keep stumbling onto more of them each week!

IP.30 is undergoing final testing and includes unbinding of broken links.

On the drawing board for function substitution is redirection to another module:
[USER32.dll]
_missing=KERNEL32.SetLastErrorand possibly module insertion:
[USER32.dll]
_missing=stubs.T16
>Substituting another function or stub for '__uncaught_exception' might {not} be acceptable to the calling app. If not, ...

I could have written "might or might not be", but chose to simplify and wrote "might be". When dealing in fuzzy logic, "not" sometimes becomes optional or even meaningless! :wacko: :lol:


>>Also, a *#.* copy of every file that is walked is created, including system DLLs (only useful if you're trying to fragment your HDD!).
>Does this relate to the "Link to copies=Y/N" option in the INI file? Would this also require "Walk dependencies=Y"?

No and Yes! IP.27 would open for R/W a copy of every file it analyzed (whether walking dep's or not) so that it could analyze and patch in one pass. Unfortunately, it didn't delete unneeded copies. Copying every file also made it slow (and loud).

"Link to copies=Y/N" determines whether an app or dll references the original or patched dependency. Naming this option to something understandable has been problematic!
Y = patch reference to refer to patched copy of dependency
needed if dependencies are patched and the (patched) app is to be directly executable N = continue to refer to original
needed if patched files are intended to be installed over originals[/list]For patched system files an installer is needed (or the file must be copies by hand in DOS). Creation of an .inf will also be tied to this option some time soon!


>>>1. Is there a way to pass command line parameters to "signtool.exe" when using the Import Patcher?
>>IP.28 reads parameters from an .ini file that can be edited between passes.
>I think that ImportPatcher.27 gave the impression that it would load and execute a file, while satisfying missing dependencies. Since that doesn't seem to be the case, my earlier question was null and void.

I misread the question about command line parameters, but now understand. Executing the patched app is a possible future feature and parameter passing would be an important design issue. Perhaps a "[Parameters] App command line parameters=" line in the .ini?
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#10
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag


Looks like MS has added a new function to a venerable support file. Substituting another function or stub for '__uncaught_exception' might {not} be acceptable to the calling app. If not, try locating a version of MSVCRT.DLL that includes this function.

Well, I found a version "7.0.6002.18005 (lh_sp2rtm.090410-1830)" on a Vista machine, dated 2009/4/11. However, although this version only reported "[Need patching? ... msvcrt.dll=Y (OS subsystem)" in ImportPatcher (with 'Walk dependencies=N'), after being patched for the OS subsystem, it looked like a descent into DLL dependency hell.

...I've just tried the Import Patcher on the "signtool.exe" utility from http://www.microsoft...ls.aspx?id=8442 (Microsoft Windows SDK for Windows 7 and .NET Framework 4). Image file = GRMSDK_EN_DVD.iso, Path = \Setup\WinSDKTools\cab1.cab, Extract file = WinSDK_signtool_exe_B2E1011D_2F14_488D_A056_C5BD55106409_x86.
...
Executing 'signtool.exe' by itself (with KernelEx 4.5.2) produces the error :

The SIGNTOOL.EXE file is
linked to missing export MSVCRT.DLL:__uncaught_exception.
...
    Importing from module: 'msvcrt.dll'
        msvcrt.dll: __uncaught_exception (db) * No match
        msvcrt.dll: ___lc_handle_func (7f) * No match
        msvcrt.dll: ___lc_codepage_func (7d) * No match
        msvcrt.dll: ___mb_cur_max_func (80) * No match
        msvcrt.dll: __pctype_func (ce) * No match
        msvcrt.dll: __iob_func (93) * No match
        msvcrt.dll: __crtLCMapStringW (8b) * No match

All seven of those functions are supported in MSVCR90.dll in the package VC_R_9X.EXE at MDGX.

If (anyone is) not running KernelEx, patch MSVCR90.dll with this function replacement:
[KERNEL32.dll]
GetSystemWindowsDirectoryW=GetWindowsDirectoryW
Put MSVCR90.dll in the same folder as signtool.exe or in <windows> or <system>.
Then add to signtoo#.ini:
[Missing modules]
msvcrt.dll=MSVCR90.dll
msvcrt.dll=MSVCR9#.dll ;or this if you don't rename after patching
This should fix the MSVCRT.DLL issues. If signtool has futher dependency problems, post the full .ini file this time (in a 'spoiler' box if large).

* Note: ImportPatcher.29 and .30 syntax (may change in other versions) *
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#11
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 5,968 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

jumper, would you be so kind as to make ImportPatcher compatible also with XP and 2k?
I can envisage many uses for it on these two OSes, too.

However, it always hangs and never finishes, when I try to use it on XP SP3.
If set to Analyse, it hangs silently, after producing the ini and the log (I have to kill it, to terminate it).
If set to Patch, it hangs before actually patching anything, and I get a box with an exclamation point saying: "Debug: CreateFileMapping"... my only option is to click OK, and whe I do it, the box closes, then reappears, keeping on this forever (so I have to kill it, to terminate it).
If run from Dependency Walker with the problem file as the only command-line argument, it analyses the file (for a real lonng time), then, after producing the ini and the log, terminates with failure. The last lines of DW profiling are the following:

00:55:39.171: First chance exception 0xC00000FD (Stack Overflow) occurred in "n:\IMPORTPATCHER.29.EXE" at address 0x00401009 by thread 1.
00:55:39.187: Second chance exception 0xC00000FD (Stack Overflow) occurred in "n:\IMPORTPATCHER.29.EXE" at address 0x00401009 by thread 1.
00:55:39.234: Exited "n:\IMPORTPATCHER.29.EXE" (process 0xA8C) with code -1073741571 (0xC00000FD) by thread 1.
00:00:00.062: Entrypoint reached. All implicit modules have been loaded.
BTW, you rock! Thanks a lot for ImportPatcher! :thumbup

#12
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

If (anyone is) not running KernelEx, patch MSVCR90.dll with this function replacement ...

Well, I'm kinda dependent on KernelEx these days ...

Anyway, I managed to get another (fairly recent) version of "signtool.exe" that doesn't have strange requirements for 'msvcrt.dll'. It's version "4.00 (longhorn_rtm.080108-2300)", obtained from the W2008 & dotNet3.5 SDK (6.0.6001.18000.367-KRMSDK_EN.iso). The file is "\Setup\WinSDKTools-WinSDKTools-common.0.cab", from which is extracted the file "signtool_exe.B68FF751_0B1A_4F33_B044_1871CB4B13CC". Also required is the "capicom.dll" file, extracted as "capicom_dll.970E4F94_546F_49F3_BF1F_18BE6B938B02".

This version of "signtool.exe" seems to run OK with KernelEx. (ImportPatcher shows mismatched hints for many DLL functions, but performance isn't important for this application.)

Joe.

#13
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

jumper, would you be so kind as to make ImportPatcher compatible also with XP and 2k?
I can envisage many uses for it on these two OSes, too.

I'll try, but I don't have any OS later than SE to test on. Good error reporting like you provided here will be important.


However, it always hangs and never finishes, when I try to use it on XP SP3.
If set to Analyse, it hangs silently, after producing the ini and the log (I have to kill it, to terminate it).

My WinMainCRTStartup function simply returned without calling exit or ExitProcess. This works in SE; apparently not in 2K+. I've added ExitProcess now.


If set to Patch, it hangs before actually patching anything, and I get a box with an exclamation point saying: "Debug: CreateFileMapping"... my only option is to click OK, and whe I do it, the box closes, then reappears, keeping on this forever (so I have to kill it, to terminate it).

The Debug message is mine and indicates that CreateFileMapping (part of the file-mapping sequence of calls) failed. I have located and fixed a minor (SE didn't mind) error in one of the protection flags. I'll also add GetLastCall support to the error reporting.

Despite forcing CreateFileMapping to fail when in patch mode, I was unable to reproduce the error loop. I'm testing IP.31 builds now and much code has been cleaned up since IP.29. I'll trace the old code in my best simulator (sleep on it) in a few minutes....


If run from Dependency Walker with the problem file as the only command-line argument, it analyses the file (for a real lonng time), then, after producing the ini and the log, terminates with failure. The last lines of DW profiling are the following:

00:55:39.171: First chance exception 0xC00000FD (Stack Overflow) occurred in "n:\IMPORTPATCHER.29.EXE" at address 0x00401009 by thread 1.
00:55:39.187: Second chance exception 0xC00000FD (Stack Overflow) occurred in "n:\IMPORTPATCHER.29.EXE" at address 0x00401009 by thread 1.
00:55:39.234: Exited "n:\IMPORTPATCHER.29.EXE" (process 0xA8C) with code -1073741571 (0xC00000FD) by thread 1.
00:00:00.062: Entrypoint reached. All implicit modules have been loaded.
BTW, you rock! Thanks a lot for ImportPatcher! :thumbup

ImportPatcher is currently designed to function recursively. A stack overflow is the expected result of a runaway loop. The slow speed is likely the result of DW managing a huge amount of text in the log window.

A (hitherto) undocumented feature of ImportPatcher is that the text of all message boxes, log file entries, and any error messages are also passed to OutputDebugMessage(). Running IP in a debug environment such as DW allows viewing of these messages. If IP is looping endlessly (until the stack overflows) the DW log window should be filling will huge amounts of text.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#14
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

Anyway, I managed to get another (fairly recent) version of "signtool.exe" that doesn't have strange requirements for 'msvcrt.dll'. It's version "4.00 (longhorn_rtm.080108-2300)", obtained from the W2008 & dotNet3.5 SDK (6.0.6001.18000.367-KRMSDK_EN.iso).
...
This version of "signtool.exe" seems to run OK with KernelEx. (ImportPatcher shows mismatched hints for many DLL functions, but performance isn't important for this application.)

The previous version was dotNet4.0--even more recent. Because KernelEx won't always be up-to-date with the latest demands of new software, it would be nice to know if ImportPatcher can help fill the void. To that end, it would be great if you could test the dotNet4.0 version with the msvcrt->msvcr90 replacement I proposed. This might also really help out those who don't use KernelEx.

TIA, jumper.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#15
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag


Anyway, I managed to get another (fairly recent) version of "signtool.exe" that doesn't have strange requirements for 'msvcrt.dll'. It's version "4.00 (longhorn_rtm.080108-2300)", obtained from the W2008 & dotNet3.5 SDK (6.0.6001.18000.367-KRMSDK_EN.iso).
...
This version of "signtool.exe" seems to run OK with KernelEx. (ImportPatcher shows mismatched hints for many DLL functions, but performance isn't important for this application.)

The previous version was dotNet4.0--even more recent. Because KernelEx won't always be up-to-date with the latest demands of new software, it would be nice to know if ImportPatcher can help fill the void. To that end, it would be great if you could test the dotNet4.0 version with the msvcrt->msvcr90 replacement I proposed. This might also really help out those who don't use KernelEx.

TIA, jumper.

Sure, but I won't get a chance to try this until Monday.

Since I do use/rely on KernelEx, for the purposes of this experiment, I presume the following will be sufficient :

* In "signtoo#.ini", I'll add :
[Missing modules]
msvcrt.dll=MSVCR90.dll

Joe.

#16
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
:rolleyes: ImportPatcher.31 is now posted.

It has the fixes I promised dencorso.

I've found enough discrepancies concerning function hints between the documentation, various guides, and what Dependency Walker reports that I've decided to disable the hints and binds features as a needless distraction at this time. The code is still in there, so it'll come back in time.

The [Missing modules] section that only appeared if a module couldn't be found is now named [Module substitutions] and is always present. Substitutions for module and function names are now made before the dependency is checked, allowing for more creative patching options. There is still a constraint, however, that substituted names must not be longer than the name they replace.

As for a more compelling new feature, I was able to alter the ending message box to provide a 'Retry' option. Now we can check the log file, edit the ini file, then click on 'Retry' to start another pass without having to reinvoke IP. (We can still click 'Cancel' to exit and then reinvoke later if we want.)

The next step is now obvious: a dialog box interface with checkboxes for the Yes/No parameters and edit boxes for the text fields, and buttons that can be labelled beyond MessageBox contraints. No more hunting for the ini or log files! :D

After that, I'll fully parse the headers and essentially relink much of the file if necessary to allow substitution of longer names and even additional modules. This will allow individual function calls to be redirected to stub libraries or even custom DLL's.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#17
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag
The future of Import Patcher looks very promising! :thumbup

Anyway, I recently encountered what appears to be a bug/quirk with IP.29. I wanted to try the RW utility here : http://rweverything.myweb.hinet.net/

What I found was that, for versions 1.4.5 and newer of RW, there is a missing dependency on 'dwmapi.dll', a Vista DLL. However, IP didn't detect this missing dependency.

Joe.

#18
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

...for versions 1.4.5 and newer of RW, there is a missing dependency on 'dwmapi.dll', a Vista DLL. However, IP didn't detect this missing dependency.

Probably a delay-load import. IP doesn't handle those yet. Try Dependency Walker--it should find it and report if it is a standard or delay load type.

Sounds like a wide-char mapi library. Try doing a preemptive module substitution with mapi32.dll or tmapi.dll; then look at what functions are reported missing.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#19
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag


The previous version was dotNet4.0--even more recent. Because KernelEx won't always be up-to-date with the latest demands of new software, it would be nice to know if ImportPatcher can help fill the void. To that end, it would be great if you could test the dotNet4.0 version with the msvcrt->msvcr90 replacement I proposed. This might also really help out those who don't use KernelEx.

TIA, jumper.

Sure, but I won't get a chance to try this until Monday.

Since I do use/rely on KernelEx, for the purposes of this experiment, I presume the following will be sufficient :

* In "signtoo#.ini", I'll add :
[Missing modules]
msvcrt.dll=MSVCR90.dll

Joe.

Well, my first attempt was thwarted because the name "MSVCR90.dll" was longer than the original "msvcrt.dll". So I copied "MSVCR90.dll" locally as "MSVCR9.dll" and did the module substitution using that name.

However, I can't get this to work. Here are the generated INI files in chronological sequence (the initial one generated by IP, my modified version, the subsequent one generated by IP) :

[ImportPatcher.31]
;Edit parameters and replacement strings, then Retry or run again to patch. <=

[Parameters]
Walk dependencies=N
Link to copies=N
Target OS=4.10

[Module substitutions]

[KERNEL32.dll]
HeapSetInformation=

[msvcrt.dll]
__uncaught_exception=
___lc_handle_func=
___lc_codepage_func=
___mb_cur_max_func=
__pctype_func=
__iob_func=
__crtLCMapStringW=
__crtGetStringTypeW=

[Patch list]
E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names
[ImportPatcher.31]
;Edit parameters and replacement strings, then Retry or run again to patch. <=

[Parameters]
Walk dependencies=N
Link to copies=N
Target OS=4.10

[Module substitutions]
msvcrt.dll=msvcr9.dll

[KERNEL32.dll]
HeapSetInformation=HeapSetInformation

[Patch list]
E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names
[ImportPatcher.31]
;Edit parameters and replacement strings, then Retry or run again to patch. <=

[Parameters]
Walk dependencies=N
Link to copies=N
Target OS=4.10

[Module substitutions]
msvcrt.dll=msvcr9.dll

[KERNEL32.dll]
HeapSetInformation=HeapSetInformation  * not found

[Patch list]
E:\Winstall\Development\Vista\710_buildtools_signtool\SignTool.exe=OS subsystem, function names, submodule names
msvcr9.dll=OS subsystem

[msvcr9.dll]
??0exception@@QAE@ABQBD@Z=
?what@exception@@UBEPBDXZ=
??1exception@@UAE@XZ=
mktime=
??0exception@@QAE@ABV0@@Z=
??0exception@@QAE@XZ=
??1bad_cast@@UAE@XZ=
??0bad_cast@@QAE@ABV0@@Z=


...for versions 1.4.5 and newer of RW, there is a missing dependency on 'dwmapi.dll', a Vista DLL. However, IP didn't detect this missing dependency.

Probably a delay-load import. IP doesn't handle those yet. Try Dependency Walker--it should find it and report if it is a standard or delay load type.

Sounds like a wide-char mapi library. Try doing a preemptive module substitution with mapi32.dll or tmapi.dll; then look at what functions are reported missing.

Well, the good news is that substituting "mapi32.dll" for "dwmapi.dll" fixes that particular dependency.

Unfortunately, after that there's a dependency on "WindowsCodecs.dll" that's more intractable. I can get this DLL online or from the dotNet 3 package, however, this has many missing function dependencies, from several other DLL's.

Joe.

#20
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag
Give it any dll that you rename to windowscodecs.dll. ;) For as long as the application that requires this dll doesn't actually need it for loading and saving image files, this should be OK (succesfully tested on RW build 1.4.9.7) B)

And btw I think I have just nicely solved the problem of the missing dnsapi.dll required by recent versions of libgio-2.0-0.dll used by GTK apps by making a dummy dnsapi.dll from the sample dll project in VC6 plus a bit of hexing. More about that later after testing a bit more, only (succesfully) tried it on a couple of unofficial Gimp 2.7.4 so far. B)

#21
loblo

loblo

    Oldbie

  • Member
  • PipPipPipPipPip
  • 761 posts
  • Joined 12-January 10
  • OS:ME
  • Country: Country Flag
By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly. :thumbup

https://skydrive.liv...D11303FA52A!128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps. :hello:

Attached Files

  • Attached File  stub.7z   13.25KB   19 downloads

Edited by loblo, 09 January 2012 - 04:35 PM.


#22
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag
Joe,

KernelEx v4.5 Beta 1 added a stub for HeapSetInformation, so you can leave that function substitution blank.

As for msvcrt.dll, try subbing 71 instead of 90:

I searched my HDD for "msvc*.dll" and came up with 36 hits (including dups). Refining the search to files containing text: "__uncaught_exception" reduced that count to 18 and these seven unique files:
 msvcr70.dll
 msvcr71.dll
 msvcr90.dll
 msvcp70.dll
 msvcp71.dll
 msvcp90.dll
 msvcm90.dll

 r = C Run-time (CRT)
 m = managed (.Net)
 p = C++ Run-time??? (Bonus points to first responder)
All seven of these missing functions appear to have been introduced in MSVC++ 7.0:
[msvcrt.dll]
__uncaught_exception
___lc_handle_func
___lc_codepage_func
___mb_cur_max_func
__pctype_func
__iob_func
__crtLCMapStringW
__crtGetStringTypeW
These 8 "functions" (variables probably) can be found in msvc 4 through 7.1, but were removed by 9:
[msvcr9.dll]
??0exception@@QAE@ABQBD@Z=
?what@exception@@UBEPBDXZ=
??1exception@@UAE@XZ=
mktime=
??0exception@@QAE@ABV0@@Z=
??0exception@@QAE@XZ=
??1bad_cast@@UAE@XZ=
??0bad_cast@@QAE@ABV0@@Z=
I don't have "8" on my system...maybe someone else can check it for these exports.

Well, my first attempt was thwarted because the name "MSVCR90.dll" was longer than the original "msvcrt.dll". So I copied "MSVCR90.dll" locally as "MSVCR9.dll" and did the module substitution using that name.

Good move--I forgot to count when I suggested it. Because table entries are word-aligned, there should actually be an extra byte available to even-lengthed strings (NULL terminator makes them odd). An additional byte or two can (usually) be stolen from the word-sized hint of the following hint-string pair. (At least one linker out there has a bug that does overlap entries half the time, making optimizing hints impossible without completely bulding the table!)

Since "msvcrt.dll" is even, look for the next beta to support subbing up to: ((length&-2)+1)

p.s. I hope everyone is having as much fun as I am. :w00t: Thanks everyone! :thumbup

Edited by jumper, 09 January 2012 - 05:17 PM.

Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#23
jds

jds

    -DOS+

  • Member
  • PipPipPipPip
  • 603 posts
  • Joined 03-June 08
  • OS:98SE
  • Country: Country Flag

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly. :thumbup

https://skydrive.liv...D11303FA52A!128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps. :hello:

Thanks, loblo. I'm sure that stub will come in handy!

So, you substituted msvcrt.dll with msvrt70.dll (renamed as msvrt7.dll), because the same trick didn't work with msvrt80 or msvcr90. Then you also created a dummy dnsapi.dll. Gotcha.

As for msvcrt.dll, try subbing 71 instead of 90:

I searched my HDD for "msvc*.dll" and came up with 36 hits (including dups). Refining the search to files containing text: "__uncaught_exception" reduced that count to 18 and these seven unique files:

 msvcr70.dll
 msvcr71.dll
 msvcr90.dll
 msvcp70.dll
 msvcp71.dll
 msvcp90.dll
 msvcm90.dll

 r = C Run-time (CRT)
 m = managed (.Net)
 p = C++ Run-time??? (Bonus points to first responder)
All seven of these missing functions appear to have been introduced in MSVC++ 7.0:
[msvcrt.dll]
__uncaught_exception
___lc_handle_func
___lc_codepage_func
___mb_cur_max_func
__pctype_func
__iob_func
__crtLCMapStringW
__crtGetStringTypeW
These 8 "functions" (variables probably) can be found in msvc 4 through 7.1, but were removed by 9:
[msvcr9.dll]
??0exception@@QAE@ABQBD@Z=
?what@exception@@UBEPBDXZ=
??1exception@@UAE@XZ=
mktime=
??0exception@@QAE@ABV0@@Z=
??0exception@@QAE@XZ=
??1bad_cast@@UAE@XZ=
??0bad_cast@@QAE@ABV0@@Z=
I don't have "8" on my system...maybe someone else can check it for these exports.

Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked! :)

As for msvcr80.dll, that doesn't have those strange-looking identifiers. (Actually, when I initially saw them, I thought they were just garbage.)

Joe.

#24
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly. :thumbup

https://skydrive.liv...D11303FA52A!128

Attached are the blank stub.dll with 4 blank export functions and the dnsapi.dll dummy made from it for GTK apps. :hello:


Wow, great work loblo!

Is KernelEx helping at all? And how did you determine what code to put into the stubs?

GTK is a popular toolkit. Qt is another. If we can get them and .Net working, a lot of apps will start to work.
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs

#25
jumper

jumper

    2014 All-American Masters HJ'er

  • Member
  • PipPipPip
  • 489 posts
  • Joined 21-January 11
  • OS:98SE
  • Country: Country Flag

By doing a substitution of msvcrt.dll for msvcr70.dll (renamed and substituted as msvcr7.dll), msvcr90 or 80 wouldn't work, on two dlls and using my dummy dnsapi.dll, I could get the latest svn build of Inkscape (uploaded just 15 hours ago at the time of this post) to run perfectly.

Good call. I tried msvcr71.dll, renamed as msvcr7.dll, and it worked! :)

So msvcr70 and msvcr71 seems to be good replacements for msvcrt. Another way to do the substitution is to put a copy renamed to msvcrt directly in the folder the the app and its dll's. And with more backwards compatibility testing, perhaps msvcr71 can be used as a direct update for msvcrt in the <system> folder. (Oops...Did I just volunteer again :blink:)
Design feedback requested:
IHAtool - IpHlpApi tester; call various functions and report results
--status-> framework is solid; 22 api's fully supported; preview release coming soon
ComDlg32 wrapper - ComDlgEx meets IpHlpApi wrapper
--status-> PrintDlgExW working in latest SumatraPDF 8^)
Future projects: ImportPatcher40 - dialog interface; Kexter - IP40+Ktree+Kexstubs




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users