none
Prozedureinsprungpunkt unterschiedliches Verhalten zwischen Win7 und WinXP

    Question

  • Hallo zusammen,

    ich habe eine MFC-Applikation mit mehreren DLL's entwickelt (VS2005 mit statisch gelinkter MFC, eine DLL ist eine Win32-DLL).

    Wenn ich die Applikation unter Win7 - 64bit starte (darunter entwickle ich auch) funktioniert alles einwandfrei.

    Wenn ich die Applikation unter WinXP - 32bit starte erscheint eine Messagebox mit folgender Meldung: Der Prozedureinsprungpunkt "EtwTraceMessage" wurde in der DLL "ntdll.dll" nicht gefunden.

    Weiß jemand an was das liegen kann?

    Danke schonmal für euer Feedback.

    Viele Grüße

    Karsten

    Tuesday, September 20, 2011 2:19 PM

Answers

  • Also die defines müssen vor den include von windows.h und afxwin.h gemacht werden!

    Eigentlich dürfte das nicht passieren, so wie Du das schilderst.

    Protokolliere doch mal den Start mit Depends, wann dieser Einsprungpunkt nicht gefunden wird. Deine Applikation kann es ja nicht sein.

    Evtl. ist ja eine andere Komponente defekt oder verantwortlich dafür.

    PS: Kann es sein, dass auf diesem 32bit XP System Dateien drauf kopiert wurden, die nicht zu diesem OS heören.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Wednesday, September 21, 2011 7:31 AM
    Moderator
  • Nach diesem Log ist NTDLL bereits geladen und erst ein späteres Modul findet scheinbar den Einsprungpunkt nicht. Was sagt denn die Debugger Ausgabe auf dem XP Rechner? (evtl. Remote-Debugging)


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Thursday, September 22, 2011 5:53 AM
    Moderator
  • Hallo Martin,

    ich habe die Ursache gefunden!

    Dummerweise war auf dem WinXP-System eine msi.dll die das Problem verursacht hat. Meine Applikation verwendet noch einige andere Third-Party-DLLs, so dass mir das nicht aufgefallen ist. msi.dll gelöscht und alles hat funktioniert.

    Man ist das peinlich!!! Aber ein Gutes hat es ja, jetzt weiß ich wie das Remote-Debugging funktioniert ;o))

    Auf jeden Fall besten Dank!!!

    Grüße Karsten

    Tuesday, September 27, 2011 8:01 AM

All replies

  • Ich wurde mal sagen Du hast WINVER oder _WIN32_WINNT zu hoch definiert.
    Dieser Einsprungpunkt kann erst ab Windows XP 64bit drin sein. (Version 5.2). Windows XP hat die Version 5.1.

    Lies http://msdn.microsoft.com/en-us/library/aa383745(VS.85).aspx


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Tuesday, September 20, 2011 2:48 PM
    Moderator
  • Hallo Martin,

    danke für deine schnelle Antwort. Ich habe gleich mal nachgeschaut: in der stdafx.h ist folgendes definiert:

    #define WINVER 0x0501

    und

    #define _WIN32_WINNT 0x0501

    und

    #define _WIN32_WINDOWS 0x0410

    Das sollte doch passen oder?

    Grüße Karsten


    • Edited by KarstenK Tuesday, September 20, 2011 3:03 PM
    Tuesday, September 20, 2011 3:02 PM
  • Und diese defines sind vor dem ersten include von windows.h gemacht?

    Und Du benutzt keine anderen Libraries, die evtl. andere Annahmen machen?

    Was sagt DEPENDS.EXE auf der 32bit Maschine. Wundert mich sowieso, das NTDLL direkt gebunden wird.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Tuesday, September 20, 2011 6:38 PM
    Moderator
  • in der Anwendung wird kein Include der windows.h gemacht, allerdings wird eine afxwin.h includiert in einer DLL genauso.

    Meine Applikation zieht eine ADVAPI32.Dll an, die wiederum die ntdll.dll anzieht.

    Die ADVAPI32.dll beinhaltet Funktionen für Registry-Aufrufe. In der ntdll.dll ist die Funktion EtwTraceMessage enthalten auf die der Einsprungspunkt fehlt.

    Nun ist es so dass auf dem WinXP-System über den DependencyWalker die EtwTraceMessage nicht angezeigt wird, aber auf dem Win7-System schon. Die Funktion gibt es wohl nur in neueren Versionen.

    Die Defines wie oben erwähnt stehen allerdings alle auf 0x0501

    Grüße

    Karsten

    Wednesday, September 21, 2011 6:58 AM
  • Also die defines müssen vor den include von windows.h und afxwin.h gemacht werden!

    Eigentlich dürfte das nicht passieren, so wie Du das schilderst.

    Protokolliere doch mal den Start mit Depends, wann dieser Einsprungpunkt nicht gefunden wird. Deine Applikation kann es ja nicht sein.

    Evtl. ist ja eine andere Komponente defekt oder verantwortlich dafür.

    PS: Kann es sein, dass auf diesem 32bit XP System Dateien drauf kopiert wurden, die nicht zu diesem OS heören.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Wednesday, September 21, 2011 7:31 AM
    Moderator
  • Von der Schilderung die Karsten gemacht hat können eigentlich nur zwei Quellen diese Ursache hervorrufen
    1. Die besagte MFC Anwendung
    2. Die besagte Win32 DLL

    Wenn die mindestens unterstützte Windows Version über Defines korrekt gesetzt ist, so wie Martin beschrieben hat, dann sollte das Problem nicht mehr auftreten. Da sollte sowohl die Anwendung als auch die Win32 DLL überprüft und ggf. mit geänderten Defines neu compiliert werden. Das Problem sollte dann nicht mehr auftreten.

    Aus meinem Verständnis hat weder die Anwendung noch die DLL weitere Abhängikeiten wenn beides statisch gelinkt ist.

    Bei der MFC Anwendung ist es sinnvoll die Defines in der "stdafx.h" vor dem ersten include hinzuzufügen. Ich meine dass die "targetver.h" erst ab VC2008 in IDE erzeugten Projekten erzeugt wird. Gibt es so einen Header, so können die defines natürlich auch da geändert werden.
    • Edited by Bordon Wednesday, September 21, 2011 8:31 AM
    Wednesday, September 21, 2011 8:28 AM
  • Hallo Martin,

    meinst du das Profiling vom DependencyWalker? SDVersion.dll ist eine MFC-DLL und DeviceDetect.dll ist eine Win32-DLL, beide auch von mir entwickelt.

    Hier das Profiling-Protokoll:

    --------------------------------------------------------------------------------
    Starting profile on 21.9.2011 at 17:58:42
    
    Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
    Program Executable: e:\auslieferung\TESTAPPSDVERSION.EXE
    Program Arguments: 
    Starting Directory: E:\Auslieferung\
    Search Path: C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\ZipGenius 6\
    
    Options Selected:
         Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
         Log DllMain calls for process attach and process detach messages.
         Hook the process to gather more detailed dependency information.
         Log LoadLibrary function calls.
         Log GetProcAddress function calls.
         Log debug output messages.
         Automatically open and profile child processes.
    --------------------------------------------------------------------------------
    
    Started "TESTAPPSDVERSION.EXE" (process 0x494) at address 0x00400000.  Successfully hooked module.
    Loaded "NTDLL.DLL" at address 0x7C910000.  Successfully hooked module.
    Loaded "KERNEL32.DLL" at address 0x7C800000.  Successfully hooked module.
    DllMain(0x7C910000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" called.
    DllMain(0x7C910000, DLL_PROCESS_ATTACH, 0x00000000) in "NTDLL.DLL" returned 1 (0x1).
    DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" called.
    DllMain(0x7C800000, DLL_PROCESS_ATTACH, 0x00000000) in "KERNEL32.DLL" returned 1 (0x1).
    Injected "DEPENDS.DLL" at address 0x08370000.
    DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" called.
    DllMain(0x08370000, DLL_PROCESS_ATTACH, 0x00000000) in "DEPENDS.DLL" returned 1 (0x1).
    Loaded "SDVERSION.DLL" at address 0x10000000.  Successfully hooked module.
    Loaded "DEVICEDETECT.DLL" at address 0x00350000.  Successfully hooked module.
    Loaded "OLE32.DLL" at address 0x774B0000.  Successfully hooked module.
    Loaded "ADVAPI32.DLL" at address 0x77DA0000.  Successfully hooked module.
    Loaded "RPCRT4.DLL" at address 0x77E50000.  Successfully hooked module.
    Loaded "SECUR32.DLL" at address 0x77FC0000.  Successfully hooked module.
    Loaded "GDI32.DLL" at address 0x77EF0000.  Successfully hooked module.
    Loaded "USER32.DLL" at address 0x7E360000.  Successfully hooked module.
    Loaded "MSVCRT.DLL" at address 0x77BE0000.  Successfully hooked module.
    Loaded "OLEAUT32.DLL" at address 0x770F0000.  Successfully hooked module.
    Loaded "COMDLG32.DLL" at address 0x76350000.  Successfully hooked module.
    Loaded "COMCTL32.DLL" at address 0x773A0000.  Successfully hooked module.
    Loaded "SHLWAPI.DLL" at address 0x77F40000.  Successfully hooked module.
    Loaded "SHELL32.DLL" at address 0x7E670000.  Successfully hooked module.
    Loaded "WINSPOOL.DRV" at address 0x72F70000.  Successfully hooked module.
    Loaded "MSI.DLL" at address 0x759B0000.  Successfully hooked module.
    Second chance exception 0xC0000139 (DLL Not Found) occurred in "NTDLL.DLL" at address 0x7C9773BE.
    Exited "TESTAPPSDVERSION.EXE" (process 0x494) with code -1073741511 (0xC0000139).
    

    Nein, außer meiner Applikation ist das ein ganz frisches System, neu aufgesetzt und noch ganz jungfäulich. SP3 ist installiert.

    Grüße Karsten

    Wednesday, September 21, 2011 4:01 PM
  • Hallo Bordon,

    die Defines stimmen, bei allen DLLs, sowie der Testapplikation, die ich geschrieben habe. Ich verstehe das auch nicht!

    Grüße Karsten

    Wednesday, September 21, 2011 4:03 PM
  • Nach diesem Log ist NTDLL bereits geladen und erst ein späteres Modul findet scheinbar den Einsprungpunkt nicht. Was sagt denn die Debugger Ausgabe auf dem XP Rechner? (evtl. Remote-Debugging)


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Thursday, September 22, 2011 5:53 AM
    Moderator
  • Wie verhält sich denn das System wenn ich die Remote-Komponenten auf dem Test-System installiere?

    Kann es sein, dass das Problem dann weg ist? Evtl. werden Dateien ausgetauscht?

    Grüße

    Karsten

    Monday, September 26, 2011 10:03 AM
  • Für den nativen Teil musst Du gar nichts installieren.
    Das geht ziemlich simpel und verändert das Systemverhalten (bis auf den Stack) nicht... so jedenfalls meine Erfahrungen.

    Der Artikel müsste eigentlich noch passen:
    http://blog.m-ri.de/index.php/2008/11/22/howtoremote-debugging-fast-and-easy/


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Monday, September 26, 2011 11:05 AM
    Moderator
  • Hallo Martin,

    der Artikel ist super, allerdings wenn ich den Prozess auf dem Testsystem starte erscheint ja gleich die Fehlermeldung. Wenn ich dort auf OK klicke beendet sich das Programm wieder. D.h. ich kann dann zwar den Prozess auswählen aber groß Debuggen kann ich nichts.

    Grüße Karsten

    Monday, September 26, 2011 11:37 AM
  • Du kannst aber auch den Prozess Remote starten. Dann müsstest Du eine Debug-Ausgabe erhalten.


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Monday, September 26, 2011 12:28 PM
    Moderator
  • Vielleicht eine blöde Frage aber wo kann ich das einstellen, welcher Prozess auf welcher Maschine gestartet werden soll?

    Danke und Grüße Karsten

    Monday, September 26, 2011 4:19 PM
  • Geh in die Debugger Projekt Einstellungen.

    Dort wählst Du Remote Debugging und wählst alles aus was Du brauchst...


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de
    Tuesday, September 27, 2011 5:52 AM
    Moderator
  • Hallo Martin,

    ich habe die Ursache gefunden!

    Dummerweise war auf dem WinXP-System eine msi.dll die das Problem verursacht hat. Meine Applikation verwendet noch einige andere Third-Party-DLLs, so dass mir das nicht aufgefallen ist. msi.dll gelöscht und alles hat funktioniert.

    Man ist das peinlich!!! Aber ein Gutes hat es ja, jetzt weiß ich wie das Remote-Debugging funktioniert ;o))

    Auf jeden Fall besten Dank!!!

    Grüße Karsten

    Tuesday, September 27, 2011 8:01 AM
  • Aber ein Gutes hat es ja, jetzt weiß ich wie das Remote-Debugging funktioniert ;o))

    Hallo KarstenK,

    Interessantes Video für das Thema: Visual Studio 2008 - Remote Debugging mithilfe von MSVSMON.EXE

    Direkter Link der sich mit Windows Media Player öffnet: http://mediadl.microsoft.com/mediadl/www/u/uk/MSDN/nuggets/MT_UsingTheRemoteDebugger.wmv

    Grüße,

    Robert

    Thursday, September 29, 2011 1:31 PM
    Owner