habe derzeit ein Problem mit der Funktion SymGetModuleInfo64 und zwar schlägt sie immer fehl :p
GetLastError sagt mir Error 87: Falscher Parameter, allerdings kapiere ich nicht, was ich falsch machen sollte. Hier mein Codesnippet:

IMAGEHLP_MODULE64	Module;

memset( &Module, 0, sizeof(IMAGEHLP_MODULE64));
Module.SizeOfStruct = sizeof(IMAGEHLP_MODULE64);

SymGetModuleInfo64( hProcess, sf.AddrPC.Offset, &Module );

hProcess hole ich zwar nicht über GetCurrentProcess (-1), sondern es ist ein "richtiges" Handle auf meinen Prozess.

dwProcessId	= GetCurrentProcessId();
hProcess	= OpenProcess( PROCESS_ALL_ACCESS, FALSE, dwProcessId );

und sf.AddrPC.Offset wird mir von der Funktion StackWalk64 zurückgegeben.

Ich habe auch den Artikel von Jochen durchgelesen: http://blog.kalmbachnet.de/?postid=67
Komischerweiße funktioniert das Testprogramm bei mir auch nicht, SymGetModuleInfo64 schlägt auch dort fehl! Könnte es wirklich an dem Bug liegen? Im System Verzeichniss ist zwar die Ver. 5.1.2600.2180 der Dbghelp.dll aber im Verzeichniss \\Debugging Tools for Windows\\ liegt die Ver. 6.6.0007.5 ?

Hoffe hier kann mir jemand helfen...

@Jochen: Sollte man sich bei deinem Codebeispiel nicht das Auflisten der Module über CreateToolhelp32Snapshot und das Laden dieser mit SymLoadModule64 sparen können, wenn man stattdessen bei SymInitialize den dritten Parameter von FALSE auf TRUE stellt? Und vl. solltest du auch noch dazuschreiben, dass UNICODE definiert sein muss um den Code kompilieren zu können.

Beides wird mit VS 7.1 und dem 2003 R2 March Edition PSDK kompiliert.

typedef struct _IMAGEHLP_MODULE64 {
    DWORD                       SizeOfStruct;           // set to sizeof(IMAGEHLP_MODULE64)
    DWORD64                     BaseOfImage;            // base load address of module
    DWORD                       ImageSize;              // virtual size of the loaded module
    DWORD                       TimeDateStamp;          // date/time stamp from pe header
    DWORD                       CheckSum;               // checksum from the pe header
    DWORD                       NumSyms;                // number of symbols in the symbol table
    SYM_TYPE                    SymType;                // type of symbols loaded
    CHAR                        ModuleName[32];         // module name
    CHAR                        ImageName[256];         // image name
    CHAR                        LoadedImageName[256];   // symbol file name
} IMAGEHLP_MODULE64, *PIMAGEHLP_MODULE64;

Vermutlich ist die Struktur im neuen PSDK größer geworden und da hat die Funktion wohl noch ein Bug drin...

Im aktuellen dbghelp.h sieht die Struktur ja so aus:

typedef struct _IMAGEHLP_MODULE64 {
    DWORD    SizeOfStruct;           // set to sizeof(IMAGEHLP_MODULE64)
    DWORD64  BaseOfImage;            // base load address of module
    DWORD    ImageSize;              // virtual size of the loaded module
    DWORD    TimeDateStamp;          // date/time stamp from pe header
    DWORD    CheckSum;               // checksum from the pe header
    DWORD    NumSyms;                // number of symbols in the symbol table
    SYM_TYPE SymType;                // type of symbols loaded
    CHAR     ModuleName[32];         // module name
    CHAR     ImageName[256];         // image name
    // new elements: 07-Jun-2002
    CHAR     LoadedImageName[256];   // symbol file name
    CHAR     LoadedPdbName[256];     // pdb file name
    DWORD    CVSig;                  // Signature of the CV record in the debug directories
    CHAR         CVData[MAX_PATH * 3];   // Contents of the CV record
    DWORD    PdbSig;                 // Signature of PDB
    GUID     PdbSig70;               // Signature of PDB (VC 7 and up)
    DWORD    PdbAge;                 // DBI age of pdb
    BOOL     PdbUnmatched;           // loaded an unmatched pdb
    BOOL     DbgUnmatched;           // loaded an unmatched dbg
    BOOL     LineNumbers;            // we have line number information
    BOOL     GlobalSymbols;          // we have internal symbol information
    BOOL     TypeInfo;               // we have type information
    // new elements: 17-Dec-2003
    BOOL     SourceIndexed;          // pdb supports source server
    BOOL     Publics;                // contains public symbols
} IMAGEHLP_MODULE64, *PIMAGEHLP_MODULE64;

Wenn Du mal in meinen Stackwalker.cpp reinschaus (Funktion "GetModuleInfo"), dann siehst Du, dass ich vor dem gleichen Problem stand... (und habs dann aber aufgegeben).
Es scheint so, also ob in der dbghelp.dll ein Vergleich der Struktur-Größe auf "==" (maximal "<=") erfolgt... was ja weder auf noch abwärtskompatibel ist...
Und da Du nun Header verwendest welche von einem aktuellen PSDK stammen und die dbghelp.dll in einer Version wo es die neuen Struktur-Elemente noch nicht gab, kommt es nun zu einem Konflikt.

Fazit: Du musst due passende dbghelp.dll mitliefern (also am besten die neueste).

Jetzt hab ich auch meine "Diskussion" mit Pat Styles wieder gefunden:
http://groups.google.de/group/microsoft.public.windbg/msg/8ced0295726a4be4

typedef struct _IMAGEHLP_MODULE64 {
    DWORD                       SizeOfStruct;           // set to sizeof(IMAGEHLP_MODULE64)
    DWORD64                     BaseOfImage;            // base load address of module
    DWORD                       ImageSize;              // virtual size of the loaded module
    DWORD                       TimeDateStamp;          // date/time stamp from pe header
    DWORD                       CheckSum;               // checksum from the pe header
    DWORD                       NumSyms;                // number of symbols in the symbol table
    SYM_TYPE                    SymType;                // type of symbols loaded
    CHAR                        ModuleName[32];         // module name
    CHAR                        ImageName[256];         // image name
    // new elements: 07-Jun-2002
    CHAR                        LoadedImageName[256];   // symbol file name
    CHAR                        LoadedPdbName[256];     // pdb file name
    DWORD                       CVSig;                  // Signature of the CV record in the debug directories
    CHAR			            CVData[MAX_PATH * 3];   // Contents of the CV record
    DWORD                       PdbSig;                 // Signature of PDB
    GUID                        PdbSig70;               // Signature of PDB (VC 7 and up)
    DWORD                       PdbAge;                 // DBI age of pdb
    BOOL                        PdbUnmatched;           // loaded an unmatched pdb
    BOOL                        DbgUnmatched;           // loaded an unmatched dbg
    BOOL                        LineNumbers;            // we have line number information
    BOOL                        GlobalSymbols;          // we have internal symbol information
    BOOL                        TypeInfo;               // we have type information
} IMAGEHLP_MODULE64, *PIMAGEHLP_MODULE64;

Beim Header der bei den Debugging Tools for Windows dabei war, siehts wie bei dir aus. Und so wie ich das verstanden habe ist keine Version mit einer anderen DLL, als der dazu ausgelieferten kompatibel. Autsch!

Wenn ich mit dem PSDK von VS 7.1 kompiliere funktioniert die Funktion
Also mit dem neuen PSDK hatte ich bisher nur Probleme

PS.: Wie kann ich in die SymGetModuleInfo64 Funktion reindebuggen?
PPS.:

yogle schrieb:

@Jochen: Sollte man sich bei deinem Codebeispiel nicht das Auflisten der Module über CreateToolhelp32Snapshot und das Laden dieser mit SymLoadModule64 sparen können, wenn man stattdessen bei SymInitialize den dritten Parameter von FALSE auf TRUE stellt?

MSDN schrieb:

fInvadeProcess
[in] If this value is TRUE, enumerates the loaded modules for the process and effectively calls the SymLoadModule64 function for each module.

Kann man sich das jetzt das explizite laden der geladenen DLLs über SymLoadModuleInfo64 sparen, oder nicht?

Beim Header der bei den Debugging Tools for Windows dabei war, siehts wie bei dir aus. Und so wie ich das verstanden habe ist keine Version mit einer anderen DLL, als der dazu ausgelieferten kompatibel. Autsch!

Wenn ich mit dem PSDK von VS 7.1 kompiliere funktioniert die Funktion
Also mit dem neuen PSDK hatte ich bisher nur Probleme

Es liegt nicht am PSDK, sondern an den Programmierern der dbghelp.dll (ist bei MS leider ein eigenes Team und weder an das OS noch an das PSDK angebunden...).

yogle schrieb:

PS.: Wie kann ich in die SymGetModuleInfo64 Funktion reindebuggen?

In VS musst Du dazu zuerst Ctrl-F11 drücken (Assembler ansicht) und dann kannst Du ganz normal mit F10 auf dem "cal"-Befehl reinspringen.

yogle schrieb:

MSDN schrieb:

fInvadeProcess
[in] If this value is TRUE, enumerates the loaded modules for the process and effectively calls the SymLoadModule64 function for each module.

Kann man sich das jetzt das explizite laden der geladenen DLLs über SymLoadModuleInfo64 sparen, oder nicht?

Ich hab da kein Vertrauen und lade die Symbole lieber selber...