DLL debuggen

[himitsu]

Moin Moin,

ich habe eine DLL und dazu eine EXE (DieTestAnwendung.dpr).

Nun wollte ich zum Debuggen der DLL diese EXE angeben
Menü > Start > Parameter
oder
Projektoptionen > Debugger

Host-Anwendung = $(OUTPUTDIR)\DieTestAnwendung.exe
Arbeitsverzeichnis = $(OUTPUTDIR)
Quellpfad = $(PROJECTDIR)

Aber irgendwie klappt das nicht, wenn ich mit Variablen arbeite (siehe das Edit-Fenster am PostBuildScript)

Es kommt vom Delphi nur

Delphi-Quellcode:

---------------------------
Fehler
---------------------------
Programm 'C:\DasVerzeichnis\%OUTPUTDIR%\DieTestAnwendung.exe' kann nicht gefunden werden.
---------------------------
OK   
---------------------------

Komisch, eigentlich war ich der Meinung, dass die relativen Pfade von der Projektdatei aus gehen, wie es z.B. bei den Ausgabepfaden der DCU und EXE der Fall ist, aber
Host-Anwendung = .\Win32\Debug\DieTestAnwendung.exe

Zitat:

Programm 'C:\DasVerzeichnis\Win32\Debug\Win32\Debug\DieTest Anwendung.exe' kann nicht gefunden werden.

so,

Delphi-Quellcode:

.\Scripting.exe

, sowie

Delphi-Quellcode:

C:\DasVerzeichnis\Win32\Debug\DieTestAnwendung.exe

funktionieren.

Aber absolute Pfade sind ein Nogo
und bei diesem relativen Pfad hab ich immer das Gefühl er wäre falsch, wenn ich ihn sehe. :freak:


Wie gebt ihr sowas dort an?

[jaenicke]

Du brauchst die Hostanwendung gar nicht angeben. Es genügt, wenn beide Projekte in der gleichen Projektgruppe sind und externe Debugsymbole aktiviert sind. Dann kannst du einfach beide Projekte erstellen und die Hostanwendung starten. Du kannst dann in Hostanwendung und DLL gleichermaßen debuggen.

Mit Variablen scheint es jedenfalls nicht zu gehen. Ich habe immer relative Pfade verwendet.

[himitsu]

Ja, alles in einer gemeinsamen Projektgruppe.
Die Projekte liegen im gleichen Verzeichnis und damit auch die Standard-Ausgabepfade an selber Stelle. (EXE und DLL nebeneinander)
Natürlich mit Debuginfos kompiliert.

Wenn ich die EXE im Debugger starte, dann wird die DLL ohne Debuginfos geladen. [edit] komisch, jetzt mit Debuginfos [/edit]

Zitat:

Modul laden: PythonScriptAX.dll. Enthält Debug-Infos. Basisadresse: $5E540000. Prozess Scripting.exe (21048)

Egal ob ich sie vorher in der aktuellen Delphi-Instanz einmal kompiliert hatte oder nicht.

Beim Starten der DLL muß mindestens die Hostanwendung angegeben sein, sonst startet der Debugger ja nicht.

Zitat:

---------------------------
Fehler
---------------------------
Projekt kann nur ausgeführt werden, wenn eine Host-Anwendung festgelegt ist. Verwenden Sie dazu das Dialogfeld "Start|Parameter...".
---------------------------
OK
---------------------------

[edit] vorhin wurde weder von der EXE, noch von der DLL aus jeweils das andere Modul gedebuggt. :gruebel:

Vorhin

[jaenicke]

So wie in deinem Edit sollte es sein. Exe starten, sobald die DLL geladen ist, kann man beide debuggen.

Das klappt leider auch hier nicht immer auf Anhieb. Neustart von Delphi und Erstellen beider Projekte hilft aber meistens.

[himitsu]

Dennoch bleibt, dass ich die relative Pfadangabe dort etwas verwirrend empfinde.
Wie gesagt, sonst ist es relativ zum Projekt, aber hier relativ zum Ausgabeverzeichnis.
[obwohl] Wo ich grade nochmal drüber nachdenke ... bezüglich RemoteDebugging, relativ zum DeployPfad. :stupid:


Nja, mehrfach neu gestartet hatte ich es schon wegen anderer nerviger Macken.
Schon, als ich nur ein Projekt gedebuggt hatte, also noch nicht übergreifend.
* Haltepunkte verschwinden ... kommen 'ne Stunden später zurück
* Haltepunkte verschieben sich, fast jedes Mal, wenn das Debuggen gestartet oder gestoppt wird.
* oft werden sie hier angezeigt, aber sind eigentlich dort
* und wenn die IDE verreckt, ist alles im Arsch, da beim "alles Speichern" nicht der Desktop gespeichert wird.
* * paar Mal ist einfach beim CodeInsight, oder wenn ich in den Property-Editor klicke, die IDE einfach so hängen geblieben
* ...

[himitsu]

boar eh ... mal geht's ne ganze Weile,
dann wieder 'ne Weile garnicht,
dann geht mal absolut garnichts
und einmal sogar falschrum, also nicht das aktive Projekt, aber dafür die fremde Seite (bei Beiden, selbst nach mehreren Wechseln hin und her)

[Andreas13]

Ja, ich weiß: ich bin nur ein blutiger Amateur im Vergleich zu Euch, und auch noch vollkommen fachfremd :( :

Zitat:

Zitat von himitsu (Beitrag 1529012)

... Aber absolute Pfade sind ein Nogo

Aber ich gehe den Weg des NoGo und halte stets den kompletten Pfad der Exe oder DLL im Quellcode fest, kopiere ihn an die richtige Stelle, und es funktioniert einfach, ohne irgendwelche Zicken der IDE.

Ich weiß, es ist überhaupt nicht professionell :oops:, aber es funktioniert bei mir immer... :-D

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1529039)

boar eh ... mal geht's ne ganze Weile,
dann wieder 'ne Weile garnicht,
dann geht mal absolut garnichts
und einmal sogar falschrum, also nicht das aktive Projekt, aber dafür die fremde Seite (bei Beiden, selbst nach mehreren Wechseln hin und her)

Ja, das ist leider so. Bei mir klappt es meistens, aber Fehler gibt es dabei leider immer wieder, egal ob z.B. mit XE6, 10.4 oder 11.3.

Zitat:

Zitat von Andreas13 (Beitrag 1529046)

Aber ich gehe den Weg des NoGo und halte stets den kompletten Pfad der Exe oder DLL im Quellcode fest, kopiere ihn an die richtige Stelle, und es funktioniert einfach, ohne irgendwelche Zicken der IDE.

Ich weiß, es ist überhaupt nicht professionell :oops:, aber es funktioniert bei mir immer... :-D

Das dürfte eher an der Größe der Projekte liegen. Bei kleineren Projekten funktioniert es bei mir auch sehr zuverlässig. Das ist ja auch der Grund, dass Embarcadero das noch nicht behoben hat. Ich bin mir sehr sicher, dass es bei deren Projekten auch besser funktioniert...

[himitsu]

:cry:

@Andreas13
Bei Pfaden, welche zur Laufzeit bestimmt werden,
oder zu Dateien, welche sich nach der Installation nicht verschieben, da sind feste Pfade OK.

Relative Pfade, wenn sie abhängig von z.B. einen veränderlichem Arbeitsverzeichnis abhängen, da sind vollkommen fehleranfällig.

Drum wird da auch immer empfohlen, dass man absolute Pfade benutzen soll, welche man z.B. oft aus einem relativen Pfad zur EXE live generiert.



Die "relativen" Pfade in den Projektoptionen sind fast alle relativ zum Projektverzeichnis (zur DPROJ).
Per se ist das immer gleich, aber man kann z.B. das ganze Projekt verschieben/umbenennen.
* innerhalb der Festplatte
* oder auf mein NAS
* oder ich könnte mein Projekt jemand Anderem geben

Da sind absolute Pfade nicht möglich,
aber relativ (so lange es innerhalb der Projektstruktur liegt) ist dort ideal.

[Andreas13]

Ich sagte doch: ich bin nur ein kleiner Amateur mit kleinen Projekten... :oops: :oops: :oops:

[himitsu]

Das fängt aber schon an, wenn du mal aufräumst
und Projekte/Verzeichnisse verschiebst/umbenennst.

Oder der PC war im Arsch und du richtest alles aus dem Backup neu ein (nicht unbedingt am selben Ort)
Das Standard-Projekteverzeichis liegt im UserVerzeichnis, da reicht es dann auch schon, wenn dein Windows-Name dann ein Anderer ist.

Außerdem hat Emba das Projekteverzeichnis lokalisiert, somit reicht es, wenn du die IDE in einer anderen Sprache anzeigst.
https://quality.embarcadero.com/browse/RSP-42499

[TiGü]

Zitat:

Zitat von jaenicke (Beitrag 1529048)

Das dürfte eher an der Größe der Projekte liegen. Bei kleineren Projekten funktioniert es bei mir auch sehr zuverlässig. Das ist ja auch der Grund, dass Embarcadero das noch nicht behoben hat. Ich bin mir sehr sicher, dass es bei deren Projekten auch besser funktioniert...

Das verstehe ich immer nicht so ganz.
Die ganze IDE-Entwicklung muss doch in der Vorgängerversion stattfinden und ich nehme mal an, dass BDS-Projekt hat schon eine gewisse Größe.
Die müssten doch schon aus reinen Selbstschutz die IDE immer wieder verbessern, weil sie ja damit arbeiten.

[Sinspin]

Wer sagt das Delphi mit sich selber geschrieben wird? So grausig wie manche Fehler in der IDE sind würde ich da auf C/C++ tippen. ...Und keiner hat Lust sich damit zu befassen.
Wenn man sich die Qualität so einiger Delphi Sourcen ansieht könnte man auch denken dass die nicht von Delphi Sprachlern gepflegt werden.

[jaenicke]

Zitat:

Zitat von TiGü (Beitrag 1529106)

Das verstehe ich immer nicht so ganz.
Die ganze IDE-Entwicklung muss doch in der Vorgängerversion stattfinden und ich nehme mal an, dass BDS-Projekt hat schon eine gewisse Größe.
Die müssten doch schon aus reinen Selbstschutz die IDE immer wieder verbessern, weil sie ja damit arbeiten.

Die haben aber sicher keine Kreuzbeziehungen bei Units oder ähnliche unsaubere Dinge im Code.

Wenn ich ein Projekt entsprechend überarbeite, funktioniert der LSP auch deutlich besser, je weiter ich da komme.

Das hat Marco Cantù vorhin hier auf der EKON auch betont, dass das ein Riesenproblem ist, wenn man solche Kreuzbeziehungen drin hat, weil sie damit nicht gut umgehen können.

[Sinspin]

Der Compiler kann es. Kaufen die den zu?

Es ist ja nicht so dass der LSP jederzeit alles neu compilieren muss. Der Nutzer arbeitet in einer Datei, an einer Stelle.
Ist schon merkwürdig dass der LSP da zu rudern hat.

[TiGü]

Zitat:

Zitat von Sinspin (Beitrag 1529126)

Wer sagt das Delphi mit sich selber geschrieben wird? So grausig wie manche Fehler in der IDE sind würde ich da auf C/C++ tippen. ...Und keiner hat Lust sich damit zu befassen.
Wenn man sich die Qualität so einiger Delphi Sourcen ansieht könnte man auch denken dass die nicht von Delphi Sprachlern gepflegt werden.

Zumindest die IDE sieht so aus wie mit VCL-Komponenten gebaut, da lag der Schluss nahe, dass da auch Delphi verwendet wird.
Anhang 56416

[jaenicke]

Zitat:

Zitat von Sinspin (Beitrag 1529148)

Der Compiler kann es. Kaufen die den zu?

Selbst wenn der Compiler nichts neu kompilieren muss, ist er aber noch für LSP eigentlich zu langsam (ohne Linken usw. natürlich). Mit Kreuzbeziehungen werden beide exponentiell langsamer.

Ich versuche jedenfalls, die Kreuzbeziehungen zu beheben. Das neue Tool, das dafür in Delphi 12 kommen soll, laut Keynote, sollte da helfen.

[dummzeuch]

Zitat:

Zitat von Sinspin (Beitrag 1529126)

Wer sagt das Delphi mit sich selber geschrieben wird?

Borland damals und alle, die sich ein wenig mit der Entwicklung von komplexeren Plugins beschäftigt haben. Es ist definitiv ein VCL-Programm (kann man mit den diversen IDE Explorer Plugins wunderbar erkennen) und ich glaube nicht, dass es mit dem C++-Builder geschrieben ist.

Es gab/gibt ein paar Ausnahmen, die in J# geschrieben waren (Teile des Refactoring ab Delphi 2007 waren zugekauft). Keine Ahnung, wie weit das inzwischen durch andere Module ersetzt wurde und ob es inzwischen wieder neue nicht-Delphi Module gibt.

[himitsu]

PS: Immernoch heißt die Haupt-Gottinstanz in der IDE TAppBuilder .... nun ratet mal, wie Delphi ursprünglich heißen sollte.

[Stevie]

Zitat:

Zitat von himitsu (Beitrag 1529257)

nun ratet mal, wie Delphi ursprünglich heißen sollte.

Appmethod? :stupid:

[himitsu]

Neee nee, das war das, wo niemand auch nur erwähnen durfte, dass es eigentlich Delphi hieß.

AppBuilder ;)


Nur kurz vor Veröffentlichung, fiel auf, dass bereits etwas so hieß.
Und weil niemandem was Besseres einfiel, blieb der interne Entwicklungsname bestehen.

[Sinspin]

Es gibt Spuren in der BDS.exe die darauf hindeuten dass zumindest das Lizenzmodul in Pascal geschrieben ist.
Das sagt aber noch nix über die IDE und den Compiler.
Ich habe auch schon in C geschriebene libs direkt in meine exe gelinkt um keine dll mitliefern zu müssen.

Der C++Builder verwendet die gleichen Klassennamen wie Delphi, das ist somit kein Beweis.
Es ist also gut möglich eine Delphi Hülle mit C/C++ Füllung vor der Nase zu haben.
Ich würde mich freuen wenn nicht.

[jaenicke]

Es wurde mehrfach betont, dass Delphi in Delphi geschrieben ist. Wäre das geändert worden, wäre solch ein Cut sicher auch aufgefallen.

[Stevie]

Die IDE ist eine VCL Anwendung, die Compiler sind in C/C++ geschrieben.

[himitsu]

Ja, ich hatte in einem Stacktrace auch schon TurboPascal-Units, welche sich im Win32-Compiler immernoch verstecken, oder war's der Debugger. :gruebel:

[himitsu]

So, also in 12.0 hat sich das Debuggen von EXE+DLL nicht verbessert. (im Momment noch das Gefühl, es ist schlimmer ... also innerhalb der zweiten Stunde)

[freimatz]

Danke für den Hinweis. :thumb:
:wall:

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1529374)

So, also in 12.0 hat sich das Debuggen von EXE+DLL nicht verbessert. (im Momment noch das Gefühl, es ist schlimmer ... also innerhalb der zweiten Stunde)

Ein Glück dass das nicht auch noch anders ist bei jeder Version.
Ich bin glücklich dass es mit 11 besser funktioniert als mit Rio wo alle paar Runden die IDE im Eimer ist weil sie sich selber dem RAM zufüllt.

Die Pfadangaben für die Host exe sind in meinem Fall zumindest kein Grund mich aufzuregen ;-)
Habe mir alles nötige drum rum programmiert als After Build Events um mein Host Programm bekommt einen Parameter damit es versteht das ich debugge und die Pfade alle falsch sind.

[himitsu]

Nee, die IDE ist zumindestens seit 10.2 beim Compilieren nicht mehr verreckt.
In XE mußte ich die Projektgruppe in 2-4 Teilen kompilieren, sonst krachte alles mit OutOfMemory, wenn zuviele Projekte auf einmal.

Wenn ich die DLL debugge, egal ob die EXE vorher neu kompiliert oder nicht, hab ich in D12 jetzt zuverlässig immer

Zitat:

Thread-Start: Thread-ID: 17328. Prozess Scripting.exe (8064)
Prozessstart: C:\Develop\ActiveScripting\Win32\Debug\Scripting.e xe. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: Scripting.exe. Ohne Debug-Infos. Basisadresse: $00EC0000. Prozess Scripting.exe (8064)
Modul laden: ntdll.dll. Ohne Debug-Infos. Basisadresse: $77AA0000. Prozess Scripting.exe (8064)

In der 11.3 war es ab und an mal so, dass da auch die Debuginfos geladen wurden und ich EXE sowie DLL gleichzeitig debuggen konnte.

Die Prozeduren mit StackFrame findet er noch, aber dann steht nur mehrmals der EXE-Name im Stacktrace, anstatt der Prodzedurnamen.

[himitsu]

Kennt sich irgendwe gut mit dem Debuggen und den Einstellungen für DebugInfos aus?


Der einfache Fall geht ja inzwischen "öfters mal".

aber ich wollte hier nun in D11 das auch endlich mal zum Laufen bringen (wir suchen grade in pgDAC einen Fehler).
* Delphi sagt es würde die Debuginfos laden ->

Delphi-Quellcode:

Modul laden: dac150.bpl. Enthält Debug-Infos. Basisadresse: $016B0000. ...

* aber weder im Stacktrace noch in den Units ist davon was zu sehn (so als wenn er sie dann nicht benutzen würde)
Sowohl in XE, als auch in 11.3 will das einfach nicht.
Es ist auch egal ob interne oder externe TDS (auch RemoteDebug noch aktiviert gehabt).


* FremdKomponenten werden mit FinalBuilder kompiliert -> Delphi-Action, also DCC32
* eigene BPL/DLL/EXE wurden in XE auch mit Delphi-Action und Eurekalog kompiliert, also ECC32 zu DCC32
* eigene BPL/DLL/EXE werden in 11.3 nun mit MSBuild kompiliert -> intern DCC32 und im AfterBuildScript der ECC

Bei den eigenen Projekten BPL/DLL/EXE funktioniert es in 11.3 nun recht gut (in XE mußten BPLs nochmal im Delphi kompiliert werden, damit DebugInfos funktionierten ... doppelte Configs und im FB mit Fehlern/Unterschieden)

Aber bei den FremdKomponenten bekomm ich es einfach nicht zum Laufen, dass ich Diese debuggen kann.
Es macht auch keinen Unterschied, ob deren Projekte in der geladenen Projektgruppe drin sind.


Früher wurden viele Packages wild über Suchpfade geholt ... inzwischen alles im EXE-/Arbeitsverzeichnis (Testsystem so wie auch bei den Kunden)
vor allem da XE und 11 parallel sich mit gleichnamigen Dateien in den Suchpfaden in die Quere kam.

[Sinspin]

Ich sag nur MadExcept, das löst 99.9% aller dieser Fragen in Luft auf.
Es gibt zwar noch immer Fälle wo was daran vorbei kracht. Gerade wenn es um eine nicht Delphi dll geht, aber alles in allem ist das schon eine feine Sache.

[himitsu]

Dort ist ein Eurekalog drin, in diesen Packages.

[Kas Ob.]

I am not sure that understand half of the former posts due the translation.

And sorry if that i am missing the point.
This line brings me to something i saw in either D2009 and D2010 years back, (or it was D2010 and XE5, i really can't remember)

Code:

Process start: C:\Develop\ActiveScripting\ Win32 \Debug\Scripting.e xe. Base address: $00EC0000. Process Scripting.exe (8064)
Load module: Scripting.exe. Without debug information . Base address: $00EC0000. Process Scripting.exe (8064)

The problem was that : EXE is not in the same folder as the dpr while the dpr of the EXE and the DLL in the ProjectGroup.

On other hand i will check and make sure to disable all Debug information handling in EurekaLog for these projects, it might introduced some regression, or test an older stable version, because EL does restructure the EXE, and could did mess something.

[Kas Ob.]

There is also something to try, move both the EXE and DLL into one folder and make sure the IDE doesn't have any opened projects, then debug from there or attach to running process.

[himitsu]

Ja, beim ursprünglichen Test hier, ging es nur um eine EXE und eine DLL, wo einfach immer alles gedebuggt werden sollte.
Aber grundsätzlich sollte es auch für alle anderen Projekte möglich sein.


Wir haben fast 100 eigene BPL/DLL/EXE (werden im FinalBuilder oder Delphi kompiliert)
und dazu noch 47 BPL und einige DLL für Fremdkomponenten, plus weitere 238 BPL vom DevExpress, welche durch den FinalBuilder erzeugt werden.
Seit unserem neuen FB-Script für D10 D11+, mit externen TDS, damit die DebugInfos sich standardmäßig einfach entfernen lassen (aber auch mit internen TDS probiert),
weil "normal" will man beim Debuggen seinen eigenen Code durchgehn, oder nur den Code einer bestimmten Komponente, und sich nicht andauernd in Fremd-Code verlaufen.

Im Moment hoffe ich noch, dass irgendwo einfach nur eine Option falsch steht, weswegen es garnicht geht.
Bei einem Teil geht es ja inzwischen, wo mit MSBuild gearbeitet wird, gegenüber den manuellen DCC32.

Es muß doch irgendwie möglich sein, dass man ohne ständiges Rumgepfusche einfach so debuggen kann, indem man im Delphi auf F9 drückt und anschließend alle vorhandenen Debuginfos benutzt werden. (das Log sagt ja, dass die Infos vorhanden sind)

[Sinspin]

Das klappt bei uns bisher eigentlich.
Project Einstellungen unter "debugging" : "true", "Debug information", "true", "Reference info", "false", "true".
Compiliert wird mit Delphi. Single exe, keine bpl, aber Dll's.
Keine Ahnung ob MadExcept/EurekaLog da noch irgendwo anders Einfluss nimmt.
Ich mache das aber eher selten via Delphi. Log und debug output sind oft schneller als durch den Code steppen.
Zumal Delphi sich gerne selber in die Beine schießt und alles in den Abgrund reißt.

[himitsu]

Zitat:

Zitat von Sinspin (Beitrag 1529696)

Das klappt bei uns bisher eigentlich.
Project Einstellungen unter "debugging" : "true", "Debug information", "true", "Reference info", "false", "true".
Compiliert wird mit Delphi. Single exe, keine bpl, aber Dll's.

NurDefinition=false und dann natürlich auch noch beim Linken aktiviert.

EXE/DLL und eigene BPL debuggen geht inzwischen meistens,
aber die "selbstkompilierten" BPLs der Fremdkomponenten gehen nicht.
also eigentlich geht es, im Prinzip, aber es will hier einfach nicht ... k.A. warum

Eigenes wird seit Kurzem mit MSBuild kompiliert -> intern ruft das aber auch nur den DCC32 auf (geht, obwohl anschließend nochmal der ECC drangelassen wird)
und Fremdes wird aktuell noch über die Delphi-Action im FinalBuilder direkt mit DCC32 kompiliert

[Kas Ob.]

OK, while i didn't completely understand the first two lines in post #35, but let me explain again, and sorry for the bad English.

We need to approach this by logic, so we can form a theory then test it, confirm a reason only after that will fix it for good, not leaving it to hit and miss and probable will work, you have testing bed with all these many files so it will be great for testing, the point is not to waste your time, but to fix this from the root, sure we need to find the root first or at least a direction.

In debugging with the IDE there is three things involved in this case.
1) Debugger module, loading the binaries EXE/DLL into memory and parsing the TDS info.
2) The IDE running the Debugger and controlling it to some extend or in full, but it will be responsible for providing the source files to browse !, and this is critical here, so it might be responsible to provide the DCU parser or the source file it self, i can't be sure if the DCUs are involved here.
3) EurekaLog that did something to the binaries headers and structure and might be even the TDS itself.

I can imagine a scenarios where (1) and (2) conflicting with each others, i don't know who is the responsible to read and access the source files, so what if the debugger found the TDS, then asked the the IDE to parse the DPR/DPROJ file to find the directories for the sources, remember that Delphi TDS doesn't have paths !
Also it could be the Debugger have its own outdated DPR/DPROJ parser, also is viable cause, what if the IDE and because the DPR/DPROJ are not saved and considered changed because EL and its modification to DPR, put the DPR at locked hence prevent the Debugger from accessing a file...
Another scenario with EL, like patched the binary and the IDE marked the DCUs as not for this binary and prevented the debugger from loading these files.

Most likely, either IDE or the Debugger or both failed to parse or access, but more seriously failed miserably to report what did really happen.

See, there is many scenarios here, and that why i asked if you try to debug that application without the DPR/DPROJ, will the debugger provide functions names ?
Just try another IDE and don't close your project, if that the case then we already greatly narrowed the search for this problem, (may be greatly is suitable to narrow :gruebel: )

[Kas Ob.]

One more thing,
After confirming if that does have something to do files and parsing, we (i mean you) will have to use ProcMon or the great ApiMonitor to compare how the IDE and its debugger behave and fail if there is a failure on some IO access, or did they read the whole TDS info or stopped parsing the header.

[Sinspin]

Zitat:

Zitat von himitsu (Beitrag 1529711)

Zitat:

Zitat von Sinspin (Beitrag 1529696)

Das klappt bei uns bisher eigentlich.
Project Einstellungen unter "debugging" : "true", "Debug information", "true", "Reference info", "false", "true".
Compiliert wird mit Delphi. Single exe, keine bpl, aber Dll's.

NurDefinition=false und dann natürlich auch noch beim Linken aktiviert.

Jup. Debug information = "true", Mapfile = "detailed", Separate TDS = "false".