[MiKl]

PROBLEMCHYLD, on 07 October 2012 - 12:29 PM, said:

DBGHELP.DLL 6.0.17.0 ??? Need some more info on this file. Google runs me in circles

I have 6.00.17.1 from OpenOffice on my system. If you like I can mail it to you.

[PROBLEMCHYLD]

jaclaz, on 08 October 2012 - 06:03 AM, said:

Actually it is written aimed to programmers and more loosely to anyone that makes a program/tool/app available for others to use.
No matter if you are a leader or a follower (or if you are a lion or a gazelle ):
http://quoteinvestig...5/lion-gazelle/
The point was only to avoid - if possible - to run in circles .

jaclaz

As I said before, it applies to followers. Now, regardless if a file breaks or enhances things, I prefer to use the latest COMPATIBLE version. I feel, if the newer files didn't serve a purpose, then they wouldn't have been created in the first place.

MiKl, on 08 October 2012 - 11:56 AM, said:

I have 6.00.17.1 from OpenOffice on my system. If you like I can mail it to you.

Thanks, but I already have that version. I was looking for any newer compatible versions with the most functions.
I have my own way of testing files, here is my method. I start from the highest version working my way backwards since most newer files provide more functions and may break things. This is why we have testers to help find any flaws with newer versions. Sometimes I miss things that others catch. If anyone has newer builds of DBGHELP.DLL, please list your version.

[Drugwash]

@PROBLEMCHYLD: Please check your PMs...

[4js]

have these found on my PC, not sure it's what you are looking for?

[PROBLEMCHYLD]

A good friend of mine has provided me with this

Version DBGHELP.DLL 5.00.2195.2104
Dependencies:	msvcrt.dll, kernel32.dll
Function exports: 76

Version DBGHELP.DLL 6.2.0013.1
Dependencies:	advapi32.dll, kernel32.dll, msvcrt.dll, rpcrt4.dll
Function exports: 119

Version DBGHELP.DLL 6.5.0003.7
Dependencies:	advapi32.dll, kernel32.dll, msvcrt.dll, rpcrt4.dll
Function exports: 184

Version DBGHELP.DLL 6.6.0007.5
Dependencies:	advapi32.dll, kernel32.dll, msvcrt.dll, rpcrt4.dll
Function exports: 204

Version DBGHELP.DLL 6.8.0004.0
Dependencies:	advapi32.dll, kernel32.dll, msvcrt.dll, rpcrt4.dll
Function exports: 205

[tomasz86]

@PROBLEMCHYLD

How do you exactly check compatibility in Win9x? In Windows 2000 the first thing I do is to use Dependency Walker to check the dependencies and then, if everything seems to be OK, I try to test the file in a real environment. Is DBGHELP.DLL from Win2k compatible with Windows 98?

If yes then you could try checking:

DBGHELP.DLL 5.1.2430.1
DBGENG.DLL 5.1.2430.1
IMAGEHLP.DLL 5.1.2430.1

These files come from XP Beta ("Whistler") and are the last versions where all Win2k APIs are present together with some new APIs from XP. In the newer versions some of the original Win2k APIs are not present any more. The three files are interdependent so you need to install all of them at the same time. You can find them in UURollup-v10c.

[PROBLEMCHYLD]

tomasz86, on 08 October 2012 - 02:16 PM, said:

How do you exactly check compatibility in Win9x?

The first thing I do is a clean install. After that, I register files whether its needed or not. This way I see if any new keys are added or if there is any corruption. I then test windows only apps [NOT ALL] because I use 98lite. If all apps are working, no memory leaks, no pop ups, no resource leaks etc... the list goes on.......... I then start adding the software I use. If I don't find any problems within a week or so, I'll call it Golden As I said earlier, I might overlook things. This is when the testers come in.

tomasz86, on 08 October 2012 - 02:16 PM, said:

In Windows 2000 the first thing I do is to use Dependency Walker to check the dependencies and then, if everything seems to be OK, I try to test the file in a real environment. Is DBGHELP.DLL from Win2k compatible with Windows 98?

Xeno86, on 10 March 2009 - 05:44 PM, said:

Problem:
Dependency Walker shows unresolved imports even if program works correctly.

Solution:
This behaviour is expected by design. Don't depend on Dependency Walker.

This is one of the reason I don't use it. Its like a bad virus scanner that gives a lot of false positives.

tomasz86, on 08 October 2012 - 02:16 PM, said:

If yes then you could try checking:

IMAGEHLP.DLL 5.1.2430.1

I already I have this included. I'll test the other files and see how they go. Thank you very much for your input.

[tomasz86]

PROBLEMCHYLD, on 08 October 2012 - 07:02 PM, said:

Problem:
Dependency Walker shows unresolved imports even if program works correctly.

Solution:
This behaviour is expected by design. Don't depend on Dependency Walker.

A meant something different

While checking for unresolved imports is also important, Dependency Walker also lists all APIs used by a file and you can easily copy them to a text file and then compare the text files of two different versions of the same file to check what the differences are.

For example:

Original Win2k SP4 DBGHELP.DLL 5.0.2195.6613:

EnumerateLoadedModules
EnumerateLoadedModules64
ExtensionApiVersion
FindDebugInfoFile
FindDebugInfoFileEx
FindExecutableImage
FindExecutableImageEx
FindFileInSearchPath
GetTimestampForLoadedLibrary
ImageDirectoryEntryToData
ImageDirectoryEntryToDataEx
ImagehlpApiVersion
ImagehlpApiVersionEx
ImageNtHeader
ImageRvaToSection
ImageRvaToVa
MakeSureDirectoryPathExists
MapDebugInformation
SearchTreeForFile
StackWalk
StackWalk64
sym
SymCleanup
SymEnumerateModules
SymEnumerateModules64
SymEnumerateSymbols
SymEnumerateSymbols64
SymEnumerateSymbolsW
SymEnumerateSymbolsW64
SymFunctionTableAccess
SymFunctionTableAccess64
SymGetLineFromAddr
SymGetLineFromAddr64
SymGetLineFromName
SymGetLineFromName64
SymGetLineNext
SymGetLineNext64
SymGetLinePrev
SymGetLinePrev64
SymGetModuleBase
SymGetModuleBase64
SymGetModuleInfo
SymGetModuleInfo64
SymGetModuleInfoEx
SymGetModuleInfoEx64
SymGetModuleInfoW
SymGetModuleInfoW64
SymGetOptions
SymGetSearchPath
SymGetSymbolInfo
SymGetSymbolInfo64
SymGetSymFromAddr
SymGetSymFromAddr64
SymGetSymFromName
SymGetSymFromName64
SymGetSymNext
SymGetSymNext64
SymGetSymPrev
SymGetSymPrev64
SymInitialize
SymLoadModule
SymLoadModule64
SymMatchFileName
SymRegisterCallback
SymRegisterCallback64
SymRegisterFunctionEntryCallback
SymRegisterFunctionEntryCallback64
SymSetOptions
SymSetSearchPath
SymUnDName
SymUnDName64
SymUnloadModule
SymUnloadModule64
UnDecorateSymbolName
UnmapDebugInformation
WinDbgExtensionDllInit

DBGHELP.DLL 5.1.2430.1

DbgHelpCreateUserDump
DbgHelpCreateUserDumpW
dh
EnumerateLoadedModules
EnumerateLoadedModules64
ExtensionApiVersion
FindDebugInfoFile
FindDebugInfoFileEx
FindExecutableImage
FindExecutableImageEx
FindFileInPath
FindFileInSearchPath
GetTimestampForLoadedLibrary
ImageDirectoryEntryToData
ImageDirectoryEntryToDataEx
ImagehlpApiVersion
ImagehlpApiVersionEx
ImageNtHeader
ImageRvaToSection
ImageRvaToVa
lm
lmi
MakeSureDirectoryPathExists
MapDebugInformation
MiniDumpReadDumpStream
MiniDumpWriteDump
omap
se
SearchTreeForFile
StackWalk
StackWalk64
sym
SymCleanup
SymEnumerateModules
SymEnumerateModules64
SymEnumerateSymbols
SymEnumerateSymbols64
SymEnumerateSymbolsW
SymEnumerateSymbolsW64
SymEnumSym
SymEnumSymbols
SymEnumTypes
SymFindFileInPath
SymFromAddr
SymFromName
SymFunctionTableAccess
SymFunctionTableAccess64
SymGetFileLineOffsets64
SymGetLineFromAddr
SymGetLineFromAddr64
SymGetLineFromName
SymGetLineFromName64
SymGetLineNext
SymGetLineNext64
SymGetLinePrev
SymGetLinePrev64
SymGetModuleBase
SymGetModuleBase64
SymGetModuleInfo
SymGetModuleInfo64
SymGetModuleInfoEx
SymGetModuleInfoEx64
SymGetModuleInfoW
SymGetModuleInfoW64
SymGetNextEnumListMember
SymGetOptions
SymGetSearchPath
SymGetSymbolInfo
SymGetSymbolInfo64
SymGetSymFromAddr
SymGetSymFromAddr64
SymGetSymFromName
SymGetSymFromName64
SymGetSymNext
SymGetSymNext64
SymGetSymPrev
SymGetSymPrev64
SymGetTypeFromName
SymGetTypeInfo
SymInitialize
SymLoadModule
SymLoadModule64
SymMatchFileName
SymRegisterCallback
SymRegisterCallback64
SymRegisterFunctionEntryCallback
SymRegisterFunctionEntryCallback64
SymSetContext
SymSetOptions
SymSetSearchPath
SymSetSymWithAddr64
SymUnDName
SymUnDName64
SymUnloadModule
SymUnloadModule64
UnDecorateSymbolName
UnmapDebugInformation
WinDbgExtensionDllInit

APIs present only in DBGHELP.DLL 5.0.2195.6613:

none

APIs present only in DBGHELP.DLL 5.1.2430.1:

DbgHelpCreateUserDump
DbgHelpCreateUserDumpW
dh
FindFileInPath
lm
lmi
MiniDumpReadDumpStream
MiniDumpWriteDump
omap
SymEnumSym
SymEnumSymbols
SymEnumTypes
SymFindFileInPath
SymGetFileLineOffsets64
SymGetNextEnumListMember
SymGetTypeFromName
SymGetTypeInfo
SymSetContext
SymSetSymWithAddr64

In this case it's clear that the latter is just an extension of the former. However, if you compare check DBGHELP.DLL 5.1.2600.5512 from XP SP3 you will see it lacks these four APIs from the original Win2k's DBGHELP.DLL:

SymGetModuleInfoEx
SymGetModuleInfoEx64
SymGetSymbolInfo
SymGetSymbolInfo64

[PROBLEMCHYLD]

Thanks, but the WinXP Beta version lacks a lot more functions than the newer versions after compared. I would assume Microsoft removed those functions because they were not needed or superceded by newer functions. Also, if I use a newer version, I don't need to add DBGENG.DLL 5.1.2430.1 because the newer files is not depended on the others. Thanks again. I'll be testing DBGHELP.DLL 6.8.4.0. This version seems to be the last one working for Win98.

[tomasz86]

PROBLEMCHYLD, on 10 October 2012 - 08:53 AM, said:

Thanks, but the WinXP Beta version lacks a lot more functions than the newer versions after compared. I would assume Microsoft removed those functions because they were not needed or superceded by newer functions.

But you never know if there aren't any other system files relying on those functions unless you check ALL of them with Dependency Walker (which is likely impossible).

[Drugwash]

tomasz86, on 10 October 2012 - 04:23 AM, said:

However, if you compare check DBGHELP.DLL 5.1.2600.5512 from XP SP3 you will see it lacks these four APIs from the original Win2k's DBGHELP.DLL:

SymGetModuleInfoEx
SymGetModuleInfoEx64
SymGetSymbolInfo
SymGetSymbolInfo64

Those four API are (apparently) exported by IMAGEHLP.DLL 5.00.2178.1. Later XP-SP3 version 5.1.2600.5512 does not export them anymore. Therefore best combination seems to be IMAGEHLP.DLL 5.00.2178.1 and DBGHELP.DLL 6.8.0004.0, unless there's other intermediary version that still exports them APIs.

I'm working on a tool that'd automatically find best choice, but it's still in alpha stage, incomplete and with a few bugs. Please bear with me, I'm well-intended but very slow.

[PROBLEMCHYLD]

Thanks Drugwash and tomasz86.

What do you SP users think about me adding this registry key

REGEDIT4

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA]
"LMCompatibility"=dword:00000003
;

It is essential to Win98 networking. It applies to any operating system that uses NTLM security. It will not break anything on the system. The reason I'm asking is because everyone don't have a network. Just to have it there is good incase needed in the future.

This post has been edited by PROBLEMCHYLD: 10 October 2012 - 01:23 PM

[Drugwash]

I say: unless it breaks anything, let it in. I got it there as part of my home network (which does involve Win7 and is not perfect but still workable using simple workaround - see my input in the Win98-Win7 connection thread).
Let's hear from other people now.

[tomasz86]

Drugwash, on 10 October 2012 - 11:00 AM, said:

Those four API are (apparently) exported by IMAGEHLP.DLL 5.00.2178.1. Later XP-SP3 version 5.1.2600.5512 does not export them anymore. Therefore best combination seems to be IMAGEHLP.DLL 5.00.2178.1 and DBGHELP.DLL 6.8.0004.0, unless there's other intermediary version that still exports them APIs.

I'm looking forward to test the tool

The last version of IMAGEHLP.DLL I know of which still supports the APIs is IMAGEHLP.DLL 5.1.2430.0 which I've already mentioned above.

[PROBLEMCHYLD]

Spoiler

BindImage
BindImageEx
CheckSumMappedFile
EnumerateLoadedModules
EnumerateLoadedModules64
FindDebugInfoFile
FindDebugInfoFileEx
FindExecutableImage
FindExecutableImageEx
GetImageConfigInformation
GetImageUnusedHeaderBytes
GetTimestampForLoadedLibrary
ImageAddCertificate
ImageDirectoryEntryToData
ImageDirectoryEntryToDataEx
ImageEnumerateCertificates
ImageGetCertificateData
ImageGetCertificateHeader
ImageGetDigestStream
ImagehlpApiVersion
ImagehlpApiVersionEx
ImageLoad
ImageNtHeader
ImageRemoveCertificate
ImageRvaToSection
ImageRvaToVa
ImageUnload
MakeSureDirectoryPathExists
MapAndLoad
MapDebugInformation
MapFileAndCheckSumA
MapFileAndCheckSumW
ReBaseImage
ReBaseImage64
RemovePrivateCvSymbolic
RemovePrivateCvSymbolicEx
RemoveRelocations
SearchTreeForFile
SetImageConfigInformation
SplitSymbols
StackWalk
StackWalk64
SymCleanup
SymEnumerateModules
SymEnumerateModules64
SymEnumerateSymbols
SymEnumerateSymbols64
SymEnumerateSymbolsW
SymEnumerateSymbolsW64
SymFunctionTableAccess
SymFunctionTableAccess64
SymGetLineFromAddr
SymGetLineFromAddr64
SymGetLineFromName
SymGetLineFromName64
SymGetLineNext
SymGetLineNext64
SymGetLinePrev
SymGetLinePrev64
SymGetModuleBase
SymGetModuleBase64
SymGetModuleInfo
SymGetModuleInfo64
SymGetModuleInfoEx
SymGetModuleInfoEx64
SymGetModuleInfoW
SymGetModuleInfoW64
SymGetOptions
SymGetSearchPath
SymGetSymbolInfo
SymGetSymbolInfo64
SymGetSymFromAddr
SymGetSymFromAddr64
SymGetSymFromName
SymGetSymFromName64
SymGetSymNext
SymGetSymNext64
SymGetSymPrev
SymGetSymPrev64
SymInitialize
SymLoadModule
SymLoadModule64
SymMatchFileName
SymRegisterCallback
SymRegisterCallback64
SymRegisterFunctionEntryCallback
SymRegisterFunctionEntryCallback64
SymSetOptions
SymSetSearchPath
SymUnDName
SymUnDName64
SymUnloadModule
SymUnloadModule64
TouchFileTimes
UnDecorateSymbolName
UnMapAndLoad
UnmapDebugInformation
UpdateDebugInfoFile
UpdateDebugInfoFileEx

tomasz86, on 10 October 2012 - 01:22 PM, said:

The last version of IMAGEHLP.DLL I know of which still supports the APIs is IMAGEHLP.DLL 5.1.2430.0 which I've already mentioned above.

The version IMAGEHLP.DLL 5.00.2178.1 is from Win ME and Drugwash is right. The Win ME versions has 99 export functions and the Win XP Beta cersion has 111 export functions. The Win XP Beta files are depended of each others while the others are not. I use the tool DLL Export Viewer v1.60 in case you were wondering

[Drugwash]

I think tomasz86's IMAGEHLP.DLL 5.1.2430.0 version is safe to use (roughly checked though). Some of the API are either duplicated between imagehlp and dbghelp, or forwarded from one-another - my tool still cannot differentiate between original exports and forwardings.

I'll make the tool available as soon as I clean the current bugs. Certain options will need much more work but at least basic functionality will be there in first public version.
I'll need some more attachment space here, otherwise it'll have to go through e-mail.

[PROBLEMCHYLD]

But then what about DBGENG.DLL 5.1.2430.1? This means we couldn't use the new DBGHELP.DLL 6.8.4.0 which IMO serves no purpose with only

DBGENG.DLL 5.1.2430.1
IMAGEHLP.DLL 5.1.2430.1

or am I missing something? Or should I avoid using DBGENG.DLL 5.1.2430.1 altogether?
I do have the following running on a test machine now

DBGHELP.DLL 5.1.2430.1
DBGENG.DLL 5.1.2430.1
IMAGEHLP.DLL 5.1.2430.1

This post has been edited by PROBLEMCHYLD: 10 October 2012 - 02:29 PM

[Drugwash]

Since DBGENG.DLL 5.1.2430.1 will only load DBGHELP.DLL with the same version and nothing else (it most likely performs an internal version check on the available dependencies and discards anything that doesn't match version and/or location), I'd say just forget about it.

I do have a newer version of DBGENG here (from Debugging Tools for Windows) - namely 6.6.0007.5, but I have a hunch it may not be fully compatible with Win9x since it only imports the Unicode versions of certain API from other modules and that usually is a sign that ANSI compatibility does not exist (at least in portions of the internal code). Might not even be redistributable, if I read the licence correctly.

Now, all XP flavors I've looked into, used DBGENG.DLL 5.1.2600.0 and it was also bound to its own paired DBGHELP.DLL, so that one is a no-no too. However, a couple of Windows 2003 versions - namely 5.2.3790.1830 and 5.2.3790.3959 - loaded fine with the default DBGHELP 6.8.0004.0 from my System folder, which means they're not bound to any particular version, therefore any of them may be a worthy replacement for the "stubborn" 5.1.x.x series.

In regard to the four missing APIs, I've performed a couple of searches on my 98SE machine (Program Files and Windows\System) and on a XP-SP3 machine (whole C drive). Query keyword was "SymGetModuleInfoEx", which is one of the missing APIs.

• On the 98SE machine I found it mentioned in ApiViewer 2004's database. Opening the application, I found all four APIs complete with prototypes but no details on them.
• On the XP machine I found it mentioned inside a virtual machine image (.vhd) that holds a long forgotten Windows 95 test installation.
• MSDN 2005 doesn't list it, nor is it mentioned anywhere (a search turned out empty). Actually none of the four appear anywhere in my local MSDN.

Based on the above, I would safely assume that the four missing APIs in IMAGEHLP.DLL are not widely used - if at all - and might be safe enough to upgrade this library to a newer version, provided it matches its dependencies. If anyone else knows better, please come forward with details.

[erpdude8]

PROBLEMCHYLD, on 07 October 2012 - 12:29 PM, said:

U98SESP3.9 coming in a few weeks
This will give you guys some time while I work on configuring my Win 7.

DBGHELP.DLL 6.0.17.0 ??? Need some more info on this file. Google runs me in circles
JSCRIPT.DLL 5.6.0.8850 Windows Server 2003 SP2
VBSCRIPT.DLL 5.6.0.8850 Windows Server 2003 SP2

you could also include the modified VCACHE.VXD v4.10.0.2223 file dated 9/20/2012 from the Vcache fix attempt forum thread into the next release of your SP as QFECheck and ME explorer shell from 98SE2ME will correctly identify the version number as build 2223.

[tomasz86]

Drugwash, on 10 October 2012 - 08:21 PM, said:

Based on the above, I would safely assume that the four missing APIs in IMAGEHLP.DLL are not widely used - if at all - and might be safe enough to upgrade this library to a newer version, provided it matches its dependencies. If anyone else knows better, please come forward with details.

I can only say that in the past I did try to replace Win2k's DBGHELP.DLL with the one from XP SP3. The system became unstable (Explorer was restarted randomly). Everything was fixed after restoring the original version.