4. _CONTEXT _X86

_CONTEXT _X86

  • Z

    Hi,

    sagt mal, ich bastele gerade n UnhandledExceptionHandler.
    Und da taucht die ContextStructur auf. Ein bissl konnte ich mir schon
    durch
    http://www.codeproject.com/KB/threads/StackWalker.aspx
    http://msdn.microsoft.com/en-us/library/ms679284(v=VS.85).aspx
    zusammensuchen.

    Die Beschreibung ist n bissl schwach. Gibt es vlt. noch ein paar andere
    referenzen??

    grüße und dank

    0
  • Mod

    Und was willst Du damit machen?
    Wozu benötigst Du den?

    Ich übergebe den einfach gleich unbesehen an einen Thread der einen Minidump erzeugt oder lasse WER den Rest machen.

    0
  • Z

    Hi Martin,

    a) was meinst Du denn mit "...lasse WER den..." ??

    b) ich habe Vectored Exception Handler registriert
    (und mittels SetUnhandledExcpetionHandler) in dem ich unter anderem
    den StackWalker von Jochen über alle threads laufen lasse. Dann gibts noch ein
    paar zusätzliche infos aus dem ExceptionRecord.
    Die ProcessHeap(s) informationen gebe ich auch raus.

    Für

    __try{
       EnterCriticalSection((LPCRITICAL_SECTION)NULL);
}
__except(EXCEPTION_EXECUTE_HANDLER)
{

};

    und

    EnterCriticalSection((LPCRITICAL_SECTION)NULL); //ohne __try{} //__except(){}

    Spricht dieser auch an (sollte ja auch) und dumped mir den CallStack und so weiter.

    Also wie Du vieleicht schon merkst, will ich mein eigenen File(Full)Dumper für unhandled runtime exception basteln.

    Jetzt zu der eigentlichen frage nochmal:

    MSDN schrieb:

    Contains processor-specific register data.

    Was icke weeß:
    CONTEXT::ESP ist der Stack pointer, zu dem stack in dem moment wo der fehler
    auftrat, EBP der instruction pointer wird ja mit StackWalker64 durchlaufen und
    mit SymGetSymFromAddr64 aus einer z.b. PDB file der symbolname geladen.

    Der Handler wird per

    mov EAX, preg
mov FS:[0], EAX

    ins frame segment geschoben, was ich leider noch net weiß ist ob die
    IDT und FS hier das gleiche wären. Da muss ich noch mal intensiver lesen.

    Auf dem Stack liegen aber auch die übergebenen Parameter, welche man ja auch
    mittels ReadProcessMemory aus dem Stack auslesen könnte.

    Respektive sogar objecte die auf dem stack initialisiert sind.

    Und genau das würde ich auch gerne:
    i) Die übergabeparameter auslesen
    ii) Die auf dem Stack Initialisierten Variablen auslesen //<--das wär n extrem geiles add on

    Nun hatte ich gehofft doch etwas mehr aus der CONTEXT structur heraus zu
    bekommen, ohne mich noch tiefer ins intel einsteigerhandbuch knien zu müssen.
    (Es geht um eine X86 prozessor architektur)

    http://www.intel.com/Assets/PDF/manual/253665.pdf
    http://www.c-plusplus.net/forum/261827

    Wär cool wenn Du mir noch ein paar infos geben könntest.

    MfG der zÄusoSc

    0
  • J

    Du solltest bei einer Exception nicht den Stackwalker laufen lassen... das macht sehr wenig sinn, denn Du müsstest ja alle Debug-Symbole mitliefern um vernünftige Ausgaben zu erhalten.

    Schreibe bei der Exceptiopn doch einfach einen MiniDump (siehe MiniDumpWriteDump).
    Die dann erzeugte Datei lässt Du Dir zukommen und Du kannst diese Datei *wie gewohnt* in VS debuggen, so als hättest Du den Absturz auf Deinem Rechner gehabt. Dazu brauchst nur *Du* die Debug-Symbole und nicht der Kunde!

    0
  • Z

    Hi Jochen,

    *das* wusste ich gar nicht. Dann ist natürlich der MiniDumpWriteDump ne echt
    coole sache. Werde ich heute mal gleich testen und evtl. n einem anderen
    thread nochmal darauf zurück kommen.

    Nur mal nebenbei:
    Mich interessiert der Zusammenhang der Interrupt Descriptor Table auf einer
    X86/64 Architektur und die verwendung des Frame Segment pointers wie
    dieser unter windows genutzt wird.

    Hättest Du da noch ein paar quellen?

    Wie kann man zwischen einem parameter und einer funktionsaddresse auf
    dem stack unterscheiden?
    ( gerade weil es ja linear abgelegt ist,..)

    So Danke erstmal. 😃
    Ich werde das mit dem minidumper nachher gleich mal ausprobieren.

    0
  • J

    Man kann ohne Debug-Infos (i.d.R.) mit den Infos auf dem Stack nichts anfangen.
    Heute werden die meisten Programme mit /FPO übersetzt, d.h. man hat keinerlei Ahnung, was auf dem Stack liegt und kann damit nichts anfangen... man kann natürlich viel erraten, aber richtiges wissen ist das nicht. Das geht dann nur noch mittels Debug-Infos (PDB-Datei).

    Was Du jetzt über die IDT und die "Segmente" wissen willst ist mir etwas unklar... Du müsstest dich zuerst mit den tiefen der Intel-Handbücher beschäftigen. Dort ist das Prinzip erklärt. Wie das unter Windows genau ist, ist auch in "Windows Internal xth Edition" teilweise erklärt.

    0
  • Z

    Wollte zwar schon loas, aber ein schneller post noch:

    In der IDT soll nach handbuch auch der exception handler stehen. Dabei
    wird eine exception wohl auch wie ein interrupt behandelt, ein neuer stack
    für den handler angelegt, der alte gesichert und auf diesen verwiesen
    ( entspricht der CONTEXT strucktur...)

    Und das ist ja, worauf das EH von windoof auch baut.

    Mich interessiert das, da ich mich früher auch mit 8 bit RISC architekturen
    beschäftigt hatte (also ich habe die in asm/C geproggt,
    n paar schaltungen dazu etc..)

    Ist Windoof Internal 5th edition die aktuelle??

    1800 Seiten Intel-papers,.... *na freu* hehehe xD

    Danke für die infos Jochen 😉

    cya

    0
  • Mod

    zeusosc schrieb:

    a) was meinst Du denn mit "...lasse WER den..." ??

    WER == Windows Error Reporting

    Man kann eine Exception einfach an WER weiterreichen. Das machen wir immer, Denn unsere Softwareist bei WinQual registriert. Damit sammelt Microsft für mich die Crashdumps...
    Setzt voraus, dass die Software signiert ist.

    Allerdings behandle ich oft den Crash auch noch selbst und erzeuge einen eigenen Dump, den der Benutzermir auch direkt senden kann (nicht anonym).

    Siehe WinQual Dienste...

    0
Anmelden zum Antworten