4. USER32 debuggen ?

USER32 debuggen ?

  • 7

    Hallo Leute,
    ich verwende die Funktion CreateWindowExA per Dllimport in einer c++/cli app um ein MessageOnlyWindow zu erzeugen. Auf einigen Computern mit IntelProzessor und Win7 oder WinXP funktioniert dies und auf einem andern Computer mit AMD Prozessor und WinXP SP3 gibt es eine System.AccessViolationException und GetLastErrorWIN32 liefert code 2 bzw. ERROR_FILE_NOT_FOUND.

    Sehr wahrscheinlich wird dieser Fehler durch Verwendung einer WIN32 Funktion im dafür nicht gedachten cli/c++ ausgelöst. Meine bisherige Netzsuche hat dazu lediglich ratlose Threads ergeben:
    http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/1b71c3e0-204b-4e0f-a302-804f47b6fe99/problem-with-createwindow-function?forum=windbg

    Allerdings würde ich mich freuen, falls mir jemand einen Tipp gibt, wie ich die USER32.dll debugge, während der Error produziert wird. Geht das mit IDA_Pro ?

    0
  • ?

    Ja, geht mit IDA.
    Setzt ein Breakpoint auf den API call und schau was da passiert ...

    0
  • J

    Oder OllyDbg, der ist sogar OpenSource.

    0
  • 7

    Danke für die Beiträge-

    Da vermutlich
    (http://blogs.msdn.com/b/dsui_team/archive/2012/11/05/troubleshooting-createwindowex-failures.aspx)

    das Problem im Kernel entsteht, werde ich es mit WinDbg versuchen (bestimmt gehen die anderen Tools aber auch).
    Welche der 3 Optionen (RS232, USB, TCP/IP mit cross over cable) zum Anschluss des Remotecomputers ist eigentlich die bessere ?

    0
  • M

    Wie kommst du eigentlich auf die Idee, Microsoft Dlls ohne Code zu debuggen? Warum solltest du irgendwas sehen, was dir weiterhilft? Ich denke, die Implementierung von CreateWindow wird nicht grad trivial sein, erst recht wenn Kernel Code beteiligt ist, da wirst in Assembler jetzt nicht unbedingt sehen, was du falsch machst. Und sehr wahrscheinlich machst du irgendwas falsch. Poste doch zumindest mal deinen Code, vielleicht sieht jemand was.

    0
  • J

    Ich glaube nicht, dass das Problem bei MS liegt.... eher an dem wie Du den Code aufrufst... und C++/CLI ist schon dafür gedacht native Code auszuführen, oder was meinst Du mit Deinem Kommentar?

    0
  • 7

    Hallo Leute – danke für die Beiträge.
    Also wie es aussieht sollte man Xp Rechner nur über ein Null Modem remote debuggen – das funktioniert ganz gut. Für Ethernet gibt es keine Unterstützung und ob IEEE oder USB geht habe ich nicht getestet. Ferner ist USER32.dll ein USER Mode Problem, dass man auch local debuggen kann – ich habe dies mal mit WinDbg auf dem einen XP Rechner A , wo CreateWindowExA mit cli/c++ ohne Fehlermeldung läuft und vergleichsweise auf dem XP Rechner B, wo es zu eingangs benannten Fehlern kommt, probiert. Im Ergebnis läuft auf beiden Rechnern der Aufruf von CreateWindowExA bis zur Marke +0x34 identisch ab. Ab da gibt es einen Unterschied den ich mir nicht erklären kann (selber Code – in beiden Fällen mit VS2008 compiliert):

    XP Rechner A (funktioniert)
Breakpoint 0 hit
eax=0012ef98 ebx=0000c0d3 ecx=00000000 edx=0012ef4c esi=001a7370 edi=00000000
eip=7e37e4a9 esp=0012ef5c ebp=0012f0a0 iopl=0         nv up ei ng nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000282
USER32!CreateWindowExA:
7e37e4a9 8bff            mov     edi,edi
0:000> p
*entfernt
0:000> p
eax=0008018c ebx=0000c0d3 ecx=7c92003d edx=00150608 esi=001a7370 edi=00000000
eip=7e37e4dd esp=0012ef5c ebp=0012f0a0 iopl=0         nv up ei ng nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000296
USER32!CreateWindowExA+0x34:
7e37e4dd c23000          ret     30h
0:000> p
eax=0008018c ebx=0000c0d3 ecx=7c92003d edx=00150608 esi=001a7370 edi=00000000
eip=746bf861 esp=0012ef90 ebp=0012f0a0 iopl=0         nv up ei ng nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000296
MSCTF!EnsureMarshalWnd+0xbe:
746bf861 50              push    eax
***
XP Rechner B (funktioniert nicht)
Breakpoint 0 hit
eax=0012ef88 ebx=0000c0a0 ecx=00000000 edx=0012ef4b esi=001a5768 edi=00000000
eip=7e37e4a9 esp=0012ef4c ebp=0012f090 iopl=0         nv up ei ng nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000282
USER32!CreateWindowExA:
7e37e4a9 8bff            mov     edi,edi
0:000> p
*entfernt
0:000> p
eax=00030220 ebx=0000c0a0 ecx=7c92005d edx=00150608 esi=001a5768 edi=00000000
eip=7e37e4dd esp=0012ef4c ebp=0012f090 iopl=0         nv up ei ng nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000296
USER32!CreateWindowExA+0x34:
7e37e4dd c23000          ret     30h
0:000> p
eax=00030220 ebx=0000c0a0 ecx=7c92005d edx=00150608 esi=001a5768 edi=00000000
eip=746bf861 esp=0012ef80 ebp=0012f090 iopl=0         nv up ei ng nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000296
MSCTF!TF_CreateCicLoadMutex+0x8876:
746bf861 50              push    eax
***

    Offensichtlich unterscheiden sich beide Aufrufe doch ab der Marke 0x34 erheblich. Weis jemand warum ?

    0
  • J

    Mach mal ein einfaches Beispielprogramm, so dass es auch jemand anders nachvollziehen kann... dann schick mir das mal...

    0
Anmelden zum Antworten