Hallo hallo! Danke für die doch zahlreichen Antworten.
Bist du dir denn sicher, dass GetMainThreadId dir auch immer den Mainthread zurückgibt?
Du gehst ja davon aus, dass der erste Thread der für den Prozess gefunden wird der Mainthread ist. Ist das irgendwo dokumentiert?
Kann mir vorstellen, dass du manchmal einfach im falschen Thread landest.
Ich bin mir relativ sicher mit der Funktion zumindest im richtigen zu landen.
Rufe ich in der _Load Funktion SetTimer() auf - was nicht mein Ziel ist, führen meine Aufrufe in der Callback Funktion in keinen Fall mehr zu einem Freeze. Rufe ich ich die gleichen Funktionen direkt in _Load auf, stürzt mir die Anwendung ab. Ich gehe also davon aus das nur der Assembler Code mit der Stack-Sicherung das Problem ist. Die ThreadId habe ich mit Breakpoints ohne das meine
Dll injiziert ist noch einmal verifiziert. Der Aufruf erfolgt ausnahmslos vom ersten erstellten Thread.
Ich bin aber wahrlich noch kein Meister mit WinDbg.
Die Funktionen, oder eher ein Teil davon meiner Ziel-Anwendung sind nicht Thread sicher, daher der Umweg.
Da es offiziell nichtmal sowas wie einen "Mainthread" gibt, ist deine Frage durchaus berechtigt
Ich gehe aber mal davon aus, dass er den Prozess suspendet erstellt und dann direkt seine
Dll injected. In diesem Falle existiert eh nur ein einziger Thread. Allerdings kann er sich dann einiges an Arbeit ersparen, indem er einfach ein wenig anders vorgeht .. deshalb auch meine Frage, was er denn eigentlich vorhat.
@Clowdy:
Mit
QueueUserAPC kannst du einen
APC registrieren, der netterweise direkt nach dem Resumen ausgeführt wird (natürlich nur in dem Falle, dass du den Prozess tatsächlich wie von mir vermutet im suspended State erstellst). Dieser
APC würde dann auch im Kontext des angegebenen Threads ausgeführt (das scheint dir ja scheinbar wichtig zu sein).
Nein ich kann auch zur Laufzeit injizieren, das Resultat bleibt aber das gleiche. Dennoch sieht die Funktion interessant aus, danke.
Darf man fragen, was du genau vor hast?
Unter x64 werden alleine schon von der calling-convention her nicht nur die GP-Register verwendet, sondern auch XMM, etc. Diese musst du ebenfalls saven und wieder restoren. Und das (R)/(E)FLAGS Register würde ich mir ebenfalls sichern, sofern du nicht 100%-ig garantieren kannst, dass deine aufgerufene Funktion die Flags nicht affektiert.
Die Register und Flags sind zwar ein Problem, aber ein lösbares ... besonders wenn man sich mal anguckt was getThreadContext sichert
Das kompliziertere Problem ist, dass du das Programm
irgendwo unterbrichst. Wenn der gerade an einer Datenstruktur rummanipuliert und deine injizierte Funktion diese auch benutzt, kann es krachen. Ähnliches Problem wie mit Unix-Signal-Handlern.
Danke für die Hinweise euch beiden, auch da werde ich mich noch einmal schlau machen.
Habt mir schon mal sehr weitergeholfen.