CPU-Fenster

[Patrick]

Hallo,

Ich hab folgendes Problem: Ich starte mein Programm und irgendwann kommt dieses CPU-Fenster. Starte ich mein Programm ohnr Delphi kommt es natürlich nicht. Aber was sagt mir dieses CPU-Fenster, und wie kann ich den Fehler beheben, es handelt sich ja schleißlich um einen Fehler, nur dass der Debugger ihn nicht ausfindig machen kann? Ich meine, mein Programm an sich läuft ja, aber es stört mich einfach.

Der Thread ist immer ein anderer
Im Fenster Links oben steht dies:

ntdll.DbgBreakPoint:
77F65554 int 3
77F65555 ret <-- Hier bleibt er stehen
77F65556 mov, edi, edi
ntdll.DbgUserBreakPoint:

Rechts unten zeigt er immer auf: 77F8C106

Daraus kann ich schon mal erkennen, dass der Fehler immer an der gleichen Stelle auftritt.
Aber wie kann ich weiter aus diesen Anzeigen lesen?

[Matze]

Hi!

ALso bei mir ist es so, dass ich den Haken, um das CPU-Fenster anzeigen zu lassen, entfernen kann.

Dann springt Delphi automatisch im Code an die Stelle, wo der Fehler auftritt.

[neolithos]

int 3 deutet eher auf einen Breakpoint hin.

[Meflin]

breakpoint steht ja auch drüber...
bist du sicher dass du keinen breakpoint gesetzt hast?

[shmia]

Zitat von Patrick:

ntdll.DbgBreakPoint:
77F65554 int 3
77F65555 ret <-- Hier bleibt er stehen
77F65556 mov, edi, edi
ntdll.DbgUserBreakPoint:

Micro$aft hat in irgendwelchen DLLs die Funktion ntdll.DbgBreakPoint vergessen.
Deshalb muss man zur Laufzeit den Programmcode patchen:

Delphi-Quellcode:

procedure PatchINT3;
var
  NOP : Byte;
  NTDLL: THandle;
  BytesWritten: DWORD;
  Address: Pointer;
begin
  if Win32Platform <> VER_PLATFORM_WIN32_NT then Exit;
  NTDLL := GetModuleHandle('NTDLL.DLL');
  if NTDLL = 0 then Exit;
  Address := GetProcAddress(NTDLL, 'DbgBreakPoint');
  if Address = nil then Exit;
  try
    if Char(Address^) <> #$CC then Exit;

    NOP := $90;
    if WriteProcessMemory(GetCurrentProcess, Address, @NOP, 1, BytesWritten) and
      (BytesWritten = 1) then
      FlushInstructionCache(GetCurrentProcess, Address, 1);
  except
    //Do not panic if you see an EAccessViolation here, it is perfectly harmless!
    on EAccessViolation do ;
    else raise;
  end;
end;

initialization

// nur wenn ein Debugger vorhanden, den Patch ausführen
if DebugHook<>0 then
   PatchINT3;

end.

Das wäre was für die Code-Library; falls jemand Lust hat....

[Patrick]

Was versteht ihr denn unter einem BreakPiont? Ich hab einen Timer drin, der im Intervall von 10 fast das ganze Programm durchläuft, aber sonst...?

Und wo sollte ich den Code jetzt einfügen und aufrufen???

[Hansa]

Ist der Quelltext denn überhaupt verfügbar, um ihn anzeigen zu können ? Der Effekt kommt bei mir nur, wenn ich lediglich die DCU habe.

[Patrick]

Also ich hab den Quellcode jetzt zu meinem Programm hinzugefügt, läuft jetzt mit Delphi ohne das CPU-Fenster!

Danke!

[Motzi]

M$ hat ein paar Dlls versehentlich mit Debug-Informationen ausgeliefert in denen noch Breakpoints drinnen waren und Delphi als pflichtbewusster Debugger hält bei diesen natürlich auch an..!

Aktuelle Service Packs sollten das Problem aber beheben..! (hat bei mir zumindest funktioniert)

[himitsu]

Das INT 3 ist halt ein netter DebugInterupt, welcher halt halt nahezu jeden Debuger dort anhalten läßt.

ich nutze dieses Verhalten ja auch öfters mal aus
ASM INT3; End; Ist halt ein praktischer BreakPoint, der auch nicht verloren geht, wenn man Delphi, oder das Projekt schließt (die normalen BreakPoint verschwinden dann ja).

Und da man ja nichts an der ntdll.dll ändern kann (die ist ja von MS), ist es nur über soeinen Patch, wie von shmia möglich dieses wegzubekommen.

Oder du versuchst mal ein paar WindowsUpdates aufzuspielen, welche diesen "Fehler" entfernen.