Archiv verlassen und diese Seite im Standarddesign anzeigen : .NET-CLR-Debugger (DbgCLR.exe)?
Ich suche das besagte Programm, kann es aber nirgends finden.
Laut MS (http://msdn.microsoft.com/en-us/library/7zxbks7z.aspx) soll sich das Tool "in the GuiDebug directory of your .NET Framework installation" befinden.
Da ist aber nichts. :confused:
Eine Internet-Recherche sagt mir, dass es den meisten Leuten so geht, irgendwie weiß keiner genau wo man das Tool herbekommt...
Hat jemand von euch eine Ahnung?
Marscel
2009-06-13, 23:47:51
Meine Internetrecherche ergab, dass das Tool nicht mehr mitgeliefert wird.
Hm hab ich schon fast befürchtet.
Was gibt es sonst noch womit man externe, managed .exe/DLLs debuggen kann?
Ich kenne sonst nur noch Reflector mit dem Debugger-Plugin 'Deblector'. Aber das funktioniert nicht besonders toll, zumal die Entwicklung des Plugins offenbar eingestellt wurde.
Gnafoo
2009-06-14, 03:57:04
Angeblich ist der Debugger im .NET 2.0 Framework SDK enthalten:
http://social.msdn.microsoft.com/forums/en/vsdebug/thread/1cfcc492-878f-4e1a-86d4-a403120ce12d/
http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=fe6f2099-b7b4-4f47-a244-c96d69c35dec
Ansonsten kann man vermutlich auch die Express Editions von Visual Studio dafür verwenden. Der enthaltene Debugger ist afaik im Prinzip der Selbe. Aber was heißt "externe" DLLs? Ohne die entsprechenden Debug-Symbole/Debug-Builds wirst du wohl nicht viel Spaß beim Debuggen haben, weil dir der Debugger (im Gegensatz zum Reflector) dann auch nur den Bytecode anzeigen kann.
Aber was heißt "externe" DLLs? Ohne die entsprechenden Debug-Symbole/Debug-Builds wirst du wohl nicht viel Spaß beim Debuggen haben, weil dir der Debugger (im Gegensatz zum Reflector) dann auch nur den Bytecode anzeigen kann.
Im Prinzip reicht mir das Debuggen des IL-Bytecodes, ich wäre froh wenn wenigstens das funktionieren würde.
Zur Situation: ich will ein ("Pre-Alpha") Programm debuggen, das aus einer exe und diversen DLLs besteht. Genau gesagt handelt es sich um "Quadrant", Bestandteil der neuen Microsoft Modeling Platform "Oslo", falls das hier ein Begriff ist (ist aber auch nicht weiter wichtig).
Mit dem Reflector kann ich wunderbar die ganzen Disassembly durchstöbern. Das besagte Debugger-Plugin sollte das Debuggen des Bytcodes ermöglichen, nur das funktioniert bei "Quadrant" nicht, bei einer eigenen Beispielanwendung dagegen schon.
Kann es sein, dass bei deployten Anwendungen eine Sperre eingebaut ist, die ein nachträgliches Debuggen des Bytecodes verhindert?
Gibt es eine Möglichkeit eine managed Anwendung in Visual Studio zu hosten, um es dann zu debuggen?
Gibt es eine Möglichkeit eine managed Anwendung in Visual Studio zu hosten, um es dann zu debuggen?
Am Prozess anhängen? Debuggen kannst du eine Anwendung allerdings nur, wenn du über deine Debug Version verfügst.
Am Prozess anhängen? Debuggen kannst du eine Anwendung allerdings nur, wenn du über deine Debug Version verfügst.
D.h. es gibt keine Möglichkeit, ein nicht selbst erstelltest Programm (ohne die Sources) zu debuggen? Schade.
D.h. es gibt keine Möglichkeit, ein nicht selbst erstelltest Programm (ohne die Sources) zu debuggen? Schade.
Wie willst du das denn anstellen? Zum Debuggen brauchst du die Debug Version und den Source. Bei der Debug Version hast du dann noch die .pdb Dateien, damit der Debugger das Kompilat auf den Source Code mappen kann.
Also ohne großen weiteren Aufwand sehe ich da jetzt sonst keien Möglichkeit.
Gnafoo
2009-06-14, 21:04:34
Also ich kann mich mit Visual Studio durchaus an Programme dranhängen, deren Debug-Symbole ich nicht habe (Tools -> Attach to Process und dann Pause). Funktioniert zumindest bei den paar .NET-Programmen, die hier grad verfügbar waren. Wirklich hilfreich ist das aber auch nicht. Ich glaube selbst mit dem Reflector o. ä. kommt man damit nicht besonders weit.
Wo genau werden die Debug-Symbole denn überall gespeichert?
Ich habe zum Test eine Anwendung (bestehend aus exe + 1 DLL) als 'Release' kompiliert und alle pdb Dateien gelöscht.
Ich kann die Anwendung trotzdem noch per Reflector oder mit der Visual Studio Methode "an den Prozess anhängen" debuggen.
Expandable
2009-06-15, 07:46:34
Soweit ich weiß, macht es bei .NET keinen großen Unterschied, ob man im Release- oder Debug-Modus kompiliert. Wichtiger (für den JITer) ist, ob gerade ein Debugger am Prozess hängt; je nach dem werden bestimmte Optimierungen ausgeschalten.
Ohne Gewähr :)
Wo genau werden die Debug-Symbole denn überall gespeichert?
Ich habe zum Test eine Anwendung (bestehend aus exe + 1 DLL) als 'Release' kompiliert und alle pdb Dateien gelöscht.
Ich kann die Anwendung trotzdem noch per Reflector oder mit der Visual Studio Methode "an den Prozess anhängen" debuggen.
Klar geht das, aber du brauchst doch den Bezug zum Sourcecode oder wie möchtest du sonst sinnvoll debuggen? Du kannst dir sogar einen eigenen Debugger bauen, mittels der Debug API. Aber wie auch immer, entweder kannst du MSIL perfekt lesen und kennst sofort die Stelle im Programm oder du müsstest dir aus der MSIL den Code reverse engineeren.
Also ich hab jetzt zumindest geklärt, warum es mit Visual Studio "Attach to process" nicht mit Bytecode Debuggen geklappt hat.
In den Debugger-Optionen war "Just my code" aktiviert.
entweder kannst du MSIL perfekt lesen und kennst sofort die Stelle im Programm oder du müsstest dir aus der MSIL den Code reverse engineeren.
Nein MSIL kann ich natürlich nicht perfekt lesen...ich hab jetzt auch eingesehen, dass das kein Sinn macht :usad:
oder du müsstest dir aus der MSIL den Code reverse engineeren.
...und ich schäzte da beginnt dann die Grauzone :biggrin:
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.