Ich finde den Fehler einfach nicht.
Ein großes Projekt mit D7 Prof erstellt.
Lasse ich das Programm in der IDE laufen und beende das Programm (nicht die IDE), so springt immer der Debugger mit dem CPU Debugger an, statt gleich zur IDE zurück zu gehen.
Der Haltepunkt ist
ntdll.DbgBreakPoint:
dort steht ein "int3" gefolgt von einem "ret"

Unter Ansicht/Debug-Fenster/Haltepunkte sind keine Haltepunkte definiert.
Trotzdem ist dieser Fehler an das Projekt gebunden, dann bei einem test-projekt taucht es nicht auf.

Wo mag die falsche Einstellung in meinem Projekt sein?

habe bei einem projekt dasselbe verhalten. grund dafür ist, dass ich ein webbrowser control im projekt habe, das ein java applet anzeigt. wenn ich in meinem programm nun das fenster mit dem webbrowser anzeige und das applet geladen wird, bleibt er beim beenden immer im cpu-fenster hängen. wenn ich das programm ausserhalb der ide laufen lasse, funktionierts einwandfrei. bei mir also kein grund zur beunruhigung.

vielleicht hilft dir das weiter.

grüße
alex

Alex,
danke für die Rückantwort, aber das ist bei mir nicht der Fall.
Da muss irgendwas anderes noch sauer sein ..

Ich habe mir eben noch mal den Aufruf-Stack bei diesem "Breakpoint" angeschaut:
ReleaseSessionHookRef
FinalizeUnits
@Halt0
Warenwirtschaft

Hmmm, hilft das jemandem weiter?

int3 hilft jedenfalls eher nicht weiter, AFAIK wird der Interrupt bei einem Breakpoint aufgerufen. Code?

Hallo,

ich hatte mal ein ähnliches Problem unter W2k. Dort hat ein MS Mittarbeiter einen Breakpoint in der API gelassen und immer beim Aufruf dieser API-Funktion hield der Debugger pflichtbewusst an. Was abhilfe schuf war letztendlich nur das nächste Service Pack. Eventuell ist es bei dir ähnlich.

Gruß
Klabautermann

Klabautermann hat folgendes geschrieben:

Hallo, ich hatte mal ein ähnliches Problem unter W2k. Dort hat ein MS Mittarbeiter einen Breakpoint in der API gelassen und immer beim Aufruf dieser API-Funktion hield der Debugger pflichtbewusst an. Was abhilfe schuf war letztendlich nur das nächste Service Pack. Eventuell ist es bei dir ähnlich. Gruß Klabautermann

Ich fass es nicht... Wie hieß denn die Funktion?

Hi,

Timosch hat folgendes geschrieben:

Ich fass es nicht... Wie hieß denn die Funktion?

kann ich nicht mehr sagen das ist schon ein paar Jahre her (bei meinem vorletzten AG). Auch wurde die Funktion von einer drittanbieter Komponente aufgerufen, so dass ich selber mit den Folgen zu kämpfen hatte aber die Ursache nicht direkt geliefert habe . Aber ein einspielen des nach einiger Zeit erschienen ServicePack hat das Problem behoben. Wenn es für dein Win schon ein entsprechend neueres gibt, würde ich es mal Probieren .

Gruß
Klabautermann

Ich setze auf dem PC ein immer aktuell gepatches XP SP2 ein.
An meinen Zusatz- (=3rd party) Komponenten habe ich die letzten Wochen nichts geändert.
Ich kann mich leider auch nicht mehr genau erinnern, wann das Problem zuerst auftrat um eventuelle Systemänderungen nachvollziehen zu können.
Ich werde (=muss ich ja wohl auch) weiterbeobachten und schauen, ob ich mehr Daten ermitteln kann.

Ich habe noch etwas weiter untersucht:
Der Debugger Break tritt in system.finalizeunits auf und es ist eine Routine in IBObjects, welche diesen Fehler auslöst (ibsession, finalization Abschnitt).
Trotzdem kann ich den Break-Trigger hier immer noch nicht lokalisieren.
Erst mal habe ich die Finalization geleert (scheint nicht allzuviel Schaden anzurichten wenn der Teil fehlt).
Vielleicht kann Jason Wharton ja mit meinem Fehlerbericht was anfangen ...

Hallo,

ich hatte mal in einem ebenfalls sehr großen Projekt dasselbe Problem. Nach wirklich intensivem Debugging bin ich darauf gestoßen, dass ein Pointer, den ich mit einer ShellAPI-Routine erzeugt hatte (genauer: eine PItemIdList-Struktur) doppelt mit der in der ActiveX-Unit verfügbaren Pointerfreigaberoutine CoTaskMemFree() freigegeben hatte. Das Problem war deswegen so schwer zu finden, weil der Fehler eben erst beim Verlassen des Programms auftrat, vorher aber nicht. Und auch dann nur mit der IDE.
Ich stimme iKilledKenny eher nicht zu, dass das kein Grund zur Beunruhigung ist. Fehlerhaftes Verhalten ist eigentlich immer ein Grund, besorgt zu sein.

Also der Debugger Break ist schon ein Problem:
In der IDE nervt er beim Verlassen der Testapplikation und beim standlone Lauf bleibt die Applikation im Speicher und der Prozessliste stehen (auch auf Kunden-PCs). Das ist schon problematisch.

Einen Schritt weiter bin ich auch noch:
Der Debugger wird ausgelost durch das FreeLibrary('GDS32.dll') mit dem die Firebird-Client-DLL entladen wird.

Dieser Schritt schlägt aber nur in meiner Applikation fehl; ich habe eine ganze Reihe von Sample-Programmen von IBObjects kompiliert,gestartet und beendet und die laufen alle einwandfrei. Also nur im Zusammenhang mit meiner Applikation ist da was faul.

Natürlich ist dieser Fehler problematisch und natürlich sollte man die Ursache finden.
IkilledKenny hat aber insofern Recht, als das der Fehler nur beim Beenden des Programms auftritt und deshalb in die Kategorie: "Na ja, wenn's keiner merkt" fällt.

Ich hatte einmal ein ähnliches Problem, der Fehler ist bis heute im System. Ich habe mir dadurch geholfen, das ich eine unsichtbare Applikation ("Henker", oder engl: "HangMan") geschrieben habe, die auf eine bestimmte Message wartet. Im lParam der Message steht ein Prozess-Handle und meine Applikation killt dann diesen Prozess einfach.

Meine fehlerbehafte Applikation hat beim "Programmende" eine Message mit dem Applikation.Handle an die unsichtbare Applikation verschickt und auf den eigenen Tod gewartet. Der nette Nebeneffekt war der, das die Applikation deutlich schneller terminiert . Klar gibt's irgendwo vielleicht Resourcenlecks, aber ich hab sie bisher nicht gefunden. Und Windows läuft auch dann noch stabil.

Es ist eine Verlegenheitslösung, aber ich war die ständigen Anrufe wegen der endlosen Fehlermeldungen einfach leid. Wie gesagt, der Fehler trat NUR beim Programmende auf und jetzt sind Alle glücklich.

So,jetzt habe ich endlich gefunden, woher die Debugger-Breaks kommen:
Es war der Application.Verifier von M$, mit dem ich mal bei einer anderen Applikation die Vista-Tauglichkeit geprüft hatte.
Dem Verifier paßt irgend etwas nicht an meiner Applikation und schießt beim Beenden die Exception raus (ein Blick in das DebugWindows bzw. das Delphi EreignisFenster halfen diesen Sachverhalt rauszukriegen).