Windows 7 64-Bit, Delphi stürzt ab!

[mkinzler]

Noch ist Windows 7 noch nicht final. Deshalb sollten wir warten, bis dies der Fall ist.

[jbg]

Zitat:

Zitat von semike

Ich persönlich bin der Meinung, dass hier Codegear eine Korrektur der beiden Debug DLLs bringen sollte. Vermutlich wird (wenn überhaupt) diese erst sehr spät kommen.

Ich glaube dass nicht mal Delphi 2009 ein Debugger-Update erhält. Weil Delphi 2010 oder wie es immer heißen mag, möglicherweise vor Windows 7 herauskommt. Und immer wenn eine neue Delphi Version drausen ist, wird die alte Version wie eine heiße Kartoffel fallen gelassen.

[himitsu]

Zitat:

Zitat von jbg

Weil Delphi 2010 oder wie es immer heißen mag,

Falls du "Comodore" meinst, dann ist dieses kein Hindernis, da dieses eine 64 Bit-Version werden soll
und es demnach mit mit den "alten" Debugger/Compilern nix gemeinsam hat.

Also könnte es da schon noch Updates geben. :angel:

[mkinzler]

Aber zuerst kommt mal Weaver (welches sich gerade im Fieldtest befindet)

[jbg]

Zitat:

Zitat von mkinzler

Aber zuerst kommt mal Weaver (welches sich gerade im Fieldtest befindet)

Und welches ich als Delphi 2010 mal bezeichne. ;-)

[stroyer]

Falls das Thema noch aktuell ist: Die Lösung/Umgehung des Problems ist relativ einfach

1) bordbk***.dll (zB. bordbk105.dll - Delphi 2007; bordbk120N.dll - Delphi 2009) in einem Hexeditor öffnen (davor Sciherungskopie erstellen)
2) nach der HEX-Folge 01 00 48 74 47 80 3D suchen
3) vergewissern, dass diese Folge nur einmal gefunden wird
4) 74 nach EB ändern
5) abspeichern

Das Problem (tritt bei allen Delphi Versionen unter Windows 7 x64 auf; manchmal tritt der Fehler erst spät oder überhaupt nicht) sollte dadurch umgangen sein, ohne dass zusätzliche Probleme entstanden sind.
Anleitung natürlich auf eigenes Risiko.

Die kleine Veränderung bewirkt, dass statt einem konditionalen Sprung (JZ oder auch 0x74) ein unkonditionaler Sprung (JMP bzw. 0xEB) steht. Dadurch wird GetLastError umgangen und somit die Situation, in der der Debugger geblockt wird.

[jbg]

Zitat:

Zitat von stroyer

Die kleine Veränderung bewirkt, dass statt einem konditionalen Sprung (JZ oder auch 0x74) ein unkonditionaler Sprung (JMP bzw. 0xEB) steht. Dadurch wird GetLastError umgangen und somit die Situation, in der der Debugger geblockt wird.

Das Problem ist, dass man nicht weiß, warum SetThreadContext (nur) unter Windows 7 zusammenbricht. Und da SetThreadContext für einen Debugger eine vitale Funktion ist, kann durch das ignorieren des Fehlers der Debugger aus dem Tritt kommen.

[mkinzler]

Das scheint mir auch eher ein Bug an Windows Seven und nicht am Debugger zu sein. So besteht ja Hoffnung, das dies noch behoben wird.

[stroyer]

Zitat:

Zitat von jbg

Zitat:

Zitat von stroyer

Die kleine Veränderung bewirkt, dass statt einem konditionalen Sprung (JZ oder auch 0x74) ein unkonditionaler Sprung (JMP bzw. 0xEB) steht. Dadurch wird GetLastError umgangen und somit die Situation, in der der Debugger geblockt wird.

Das Problem ist, dass man nicht weiß, warum SetThreadContext (nur) unter Windows 7 zusammenbricht. Und da SetThreadContext für einen Debugger eine vitale Funktion ist, kann durch das ignorieren des Fehlers der Debugger aus dem Tritt kommen.

Immerhin kann man dann aber debuggen. Ich bezweifle jedenfalls, dass dieses Problem auf andere Weise in nächster Zeit behoben wird. Alleine weil der Debugger auf 32bit Basis läuft.

[jbg]

Zitat:

Zitat von mkinzler

Das scheint mir auch eher ein Bug an Windows Seven und nicht am Debugger zu sein. So besteht ja Hoffnung, das dies noch behoben wird.

Und wenn niemand sich bei Microsoft rührt, werden die auch nichts machen.