Dieser Artikel wurde maschinell übersetzt.

Tiefe Einblicke in CLR

Verbesserungen bei der Produktionsdiagnose in CLR 4

Jon Langdon

Die Common Language Runtime (CLR)-Team haben wir eine Gruppe, deren Fokus zur Verfügung stellt, APIs und Dienste, die andere Diagnoseprogramme für verwalteten Code zu erstellen. Die zwei größten Komponenten, die wir besitzen (hinsichtlich der technischen Ressourcen dediziert) sind, das verwaltete Debuggen und Profilerstellung von APIs (ICorDebug * und ICorProfiler * bzw.).

Wie der restliche der CLR und Framework-Teams ist der Wert nur über die Anwendungen über unsere Beiträge realisiert. Z. B. Visual Studio-Teams beanspruchen, diese Debuggen und Profilerstellung von APIs für Ihre verwalteten Debugger und Profilerstellungstools Leistung und eine Reihe von Drittanbieter-Entwickler sind Tools, mit der Profilerstellungs-API erstellen.

Für die letzten 10 Jahren viel in diesem Bereich für die CLR und die Visual Studio den Fokus wurde zum Aktivieren der desktop Szenarien für Entwickler: Quelle in einem Debugger nach Codefehler; Starten einer Anwendung unter einem Profiler Leistung zu langsamen Codepfade; lokalisieren stepping bearbeiten und Fortfahren um Zeitaufwand im Edit-Build-Debuggen-Zyklus zu reduzieren und so weiter. Diese Tools können nützlich zum Auffinden von Fehlern in Ihren Anwendungen, nachdem Sie haben wurde auf dem Computer eines Benutzers installiert oder zur Bereitstellung auf einem Server (beide Anfragen im folgenden als bezeichnet werden Produktion), und wir verfügen über eine Anzahl von Drittanbietern erstellen erstklassiger Produktion Diagnoseprogramme über unsere Arbeit.

Allerdings erhalten wir konsistent Feedback von Kunden und diesen Lieferanten Stresstesten die Bedeutung der vereinfacht sogar Fehler während der gesamten Lebensdauer einer Anwendung finden. Nachdem alle gelten Softwarefehler im Allgemeinen teurer zu beheben, desto höher sind diese im Lebenszyklus Anwendung gefunden werden.

CLR-4 (die Common Language Runtime zugrunde liegende Microsoft .NET Framework, 4) ist die erste Version, die in der wir einen erheblichen Aufwand zur Behebung dieses Feedback und erweitern die Szenarios beginnen unsere Diagnose APIs unterstützen bis zum Ende des Spektrums Produktion vorgenommenen.

In diesem Artikel wird ich einige der Szenarios, die wir für heute, insbesondere mühsam sein Verstehen der Ansatz betrachten wir dauert, lösen Sie und die Arten von Tools, die Sie aktivieren möchten. Ich werde insbesondere erklären, wie wir die Debug-API zur Unterstützung von Dump Debuggen entwickelt haben für die Anwendung Absturz - hängt Szenarien und wie wir es leichter zu erkennen, wann vorgenommenen hängt durch Multithreading Probleme verursacht werden.

Ich wird auch beschreiben, wie hinzufügen die Fähigkeit zum Anfügen von Profilerstellungstools zu einer bereits ausgeführten Anwendung wird weiter vereinfachen Problembehandlung dieser gleichen Szenarien, und deutlich reduzieren die benötigte Zeit zum Diagnostizieren von Problemen, die durch eine übermäßige Speicherbelegung verursacht.

Schließlich wird ich kurz erläutern, wie wir Profilerstellungstools einfacher bereitstellen, weil die Abhängigkeit von der Registrierung vorgenommen. In der gesamten haben der Schwerpunkt liegt in erster Linie auf die Typen der neuen Tools, die unsere Arbeit ermöglicht enthalten, jedoch gegebenenfalls ich Verweise auf zusätzliche Ressourcen, mit die Hilfe Sie verstehen, wie Sie unsere Arbeit über Visual Studio nutzen können.

Dump Debuggen

Ein beliebtes Feature, das wir mit Visual Studio 2010 übermitteln sind, verwaltete Dump Debuggen. Prozess-Dumps, i. d. r. nur als Dumps, bezeichnet werden häufig in der Produktion Debugszenarios für systemeigenen und verwalteten Code verwendet. Ein Speicherabbild ist im Wesentlichen einen Snapshot der Prozessstatus zu einem bestimmten Zeitpunkt. Insbesondere dessen den Inhalt des virtuellen Speichers des Prozesses (oder einige Teilmenge davon) in eine Datei ausgegeben.

Vor mussten Visual Studio 2010 zum Debuggen von verwaltetem Code Dumps für Sie die spezielle Windows-Debugger Erweiterung sos.dll verwenden, um die Speicherabbilder anstelle von vertrauten Tools wie Visual Studio zu analysieren, (wobei Sie wahrscheinlich geschrieben und Debuggen von Code während der Produktentwicklung). Unser Ziel für die allgemeine Benutzerfreundlichkeit möchten wir Ihnen, wenn ein Speicherabbild zum Diagnostizieren von Problemen in Visual Studio mit, dass der angehalten-Zustand Debuggen Leben ist: Was Sie auftreten, wenn Sie Code Debuggen sind und an einem Haltepunkt angehalten.

Die am häufigsten verwendeten Zeitpunkt zum Sammeln von Dumps ist, wenn eine unbehandelte Ausnahme in einer Anwendung, einen Absturz verursacht. Verwenden Sie den Dump herausfinden, warum der Absturz, in der Regel anhand der Aufrufliste des fehlerhaften Threads starten aufgetreten. Andere Szenarien, in denen Dumps verwendet werden, sind Application Hangs und Probleme bei der Verwendung des Arbeitsspeichers.

Beispielsweise wenn Ihre Website beendet wurde, Verarbeiten von Anforderungen, können Sie einen Debugger anfügen, ein Speicherabbild zu sammeln und die Anwendung neu starten. Offlineanalyse der Sicherung kann beispielsweise anzeigen, sind alle Ihre Threads, die Verarbeitung von Anforderungen für eine Verbindung zur Datenbank bereit, oder vielleicht einen Deadlock im Code suchen. Speicherverwendung Probleme können auf verschiedene Weise aus Sicht des Endbenutzers Anwendungsmanifest: Die Anwendung aufgrund der übermäßigen Garbagecollection verlangsamt; Dienst ist unterbrochen, weil die Anwendung nicht genügend virtuellen Arbeitsspeicher und, benötigt um neu gestartet werden; und so weiter.

Durch CLR 2 bereitgestellt die Debug-APIs Unterstützung für das Debuggen von laufenden Prozessen, nur die Tools, mit die soeben beschriebenen Szenarien target schwierig durchgeführt. Die API wurde im Grunde nicht Dump Debugszenarios Bedenken entwickelt. Die Tatsache, dass die API einen Helper-Thread in die Zielprozess ausgeführt wird, auf Dienstanforderungen von Debugger verwendet diesen Punkt durch Unterstriche.

Z. B. wenn möchte, dass ein verwalteter Debugger Durchlaufen eines Threadstapels sendet in CLR 2 es eine Anforderung an die Hilfs-Thread im Prozess gedebuggt wird. Die CLR in diesem Prozess die Anforderung und gibt die Ergebnisse an den Debugger. Da ein Speicherabbild nur eine Datei handelt, ist gibt es kein Hilfs-Thread zur Verarbeitung von Anforderungen in diesem Fall.

Die Bereitstellung eine Lösung für das Debuggen von verwalteten Codes in eine Speicherabbilddatei, musste eine API erstellen, das Ausführen von Code in das Ziel zum Überprüfen von verwaltetem Code Zustand nicht erforderlich war. Doch da debugger-Verfasser (hauptsächlich Visual Studio) bereits eine erhebliche Investition in die CLR-Debuggen-API Livedebuggen bereitzustellen, wir nicht die Verwendung von zwei verschiedenen APIs erzwingen möchten.

Wir in CLR 4 Bezugskosten wurde Neuimplementieren eine Anzahl der Debug-APIs (in erster Linie die zur Überprüfung von Code und Daten erforderlich sind), die Verwendung der Hilfs-Thread zu entfernen. Das Ergebnis ist, dass die vorhandene-API nicht mehr wichtig sind, ob das Ziel einer Speicherabbilddatei oder einen live-Prozess ist. Darüber hinaus sind Debugger Autoren derselben API zum Ziel verwenden beide live und Debugszenarios ausgeben können. Wenn live speziell für die Steuerung der Ausführung Debuggen – Festlegen von Haltepunkten und das schrittweise Ausführen von Code – die Debug-API weiterhin einen Helper-Thread verwendet. Langfristig möchten wir die Abhängigkeit für diese Szenarios sowie zu entfernen. Rick Byers (ein ehemaliger Entwickler auf die Debugdienste-API) verfügt über nützliche Blogbeiträgen, die diese Arbeit am ausführlicher beschreiben.Blogs.msdn.com/rmbyers/archive/2008/10/27/ICorDebug-Re-Architecture-in-CLR-4-0.aspx.

ICorDebug können jetzt Überprüfen von verwaltetem Code und Daten in einer Speicherabbilddatei: Durchlaufen von Stapeln, Aufzählen von lokalen Variablen, den Ausnahmetyp und so weiter. Für Abstürze und Blockaden steht oft ausreichend Kontext aus dem Threadstapel und Zusatzkomponenten Daten, um die Ursache des Problems zu finden.

Während wir wissen, dass die Speicherdiagnose und andere Szenarien außerdem wichtig sind, wir einfach nicht verfügt ausreichend Zeit im Zeitplan CLR 4 neue APIs zu erstellen, die Debugger zu untersuchen des verwalteten Heaps auf die Art und Weise gewähren, ist dieses Szenario erforderlich. Nach vorne verschieben, wie wir auch weiterhin die Produktion Diagnose Szenarios erweitern, die wir unterstützen dies etwas ist wir hinzufügen wird erwartet. Weiter unten in diesem Artikel erläutern ich anderen arbeiten wir gemacht haben, damit die Adresse dieses Szenarios.

Ich möchte auch explizit aufrufen, dass diese Arbeit 32- und 64-Bit-Ziele und nur verwaltet sowohl im gemischten Modus (systemeigen und verwaltet) Debuggen unterstützt. Visual Studio 2010 bietet im gemischten Modus für Dumps, verwalteten Code enthält.

Bildschirm sperren-Überprüfung

Multithread-Programmierung kann schwierig sein. Ob Sie explizit schreiben Multithreaded Code Netzwerkzugriffsgeräten Frameworks oder Bibliotheken, die es für Sie tun, kann die Diagnose von Problemen im asynchronen und parallelen Code recht anspruchsvoll sein. Wenn Sie eine logische Einheit der Arbeit in einem einzigen Thread ausgeführt haben, verstehen Kausalitäts ist viel einfacher und kann häufig ermittelt werden, indem einfach Aufrufliste des Threads betrachtet. Aber, dass die Arbeit auf mehrere Threads aufgeteilt ist, den Datenfluss Ablaufverfolgung wird wesentlich schwieriger. Warum wird die Arbeit nicht werden abgeschlossen? Ist ein Teil davon auf ein Objekt gesperrt?

Mit mehreren Kernen immer alltäglich, Entwickler suchen mehr und mehr parallele Programmierung als ein Mittel zur Leistungsverbesserung, anstatt einfach auf die Geschwindigkeit Fortschritte chip. Microsoft-Entwickler sind in dieser Charge enthalten und in den vergangenen Jahren wir haben bereits deutlich konzentriert erleichtert es Entwicklern, die in diesem Bereich erfolgreich durchgeführt werden. Im Hinblick auf die Diagnose hinzugefügt haben wir die Komplexität von Multithreaded Code ein paar einfachen und dennoch hilfreich APIs, die es, Tools ermöglichen, mit denen Entwickler besser bewältigen.

Die CLR-Debug-APIs haben wir Inspektion APIs für Monitor-Sperren hinzugefügt. Einfach ausgedrückt,-Monitore bieten eine Möglichkeit für Programme, um den Zugriff auf eine freigegebene Ressource (ein Objekt in Ihrem .NET-Code) über mehrere Threads zu synchronisieren. Also während ein Thread die Ressource gesperrt hat, wartet ein anderer Thread. Wenn der Thread die Sperre besitzt es freigibt, kann der erste Thread warten nun die Ressource abrufen.

In .NET Framework Monitore direkt über die System.Threading.Monitor-Namespace, aber im Allgemeinen über die lock- und SyncLock-Schlüsselwörter in c# und Visual Basic bzw. unterliegen. Sie sind auch in der Implementierung von synchronisierten Methoden, der Task Parallel Library (TPL) und andere asynchrone Programmiermodelle verwendet. Die neuen Debug-APIs können Sie besser zu verstehen, welches Objekt gegebenenfalls auf ein bestimmten Thread blockiert ist und welche Threads ggf. eine auf ein bestimmtes Objekt Sperre. Nutzen diese APIs, helfen Debuggern Entwicklern Deadlocks lokalisieren und verstehen, wenn mehrere Threads für eine Ressource (Sperre Convoys) konkurriert Leistung einer Anwendung beeinflusst werden können.

Ein Beispiel für die Art der Tools für die diese arbeiten kann, die Debugfeatures in Visual Studio 2010 Parallel auschecken. Daniel Moth und Stephen Toub bereitgestellt einen hervorragenden Überblick über diese in der Ausgabe vom September 2009 von .MSDN Magazine (MSDN.Microsoft.com/magazine/ee410778).

Eines der Dinge, die uns die am häufigsten über den Dump Debuggen Arbeit ist, erstellen eine abstrakte Sicht von das Debugziel Inspektion Funktionsumfang bedeutet, dass excites wird, wie die Monitor-Lock-Inspection, hinzugefügt, mit dem Wert für beide live und Dump Debugszenarios bereitstellt. Während ich erwarte, dieses Feature dass werden äußerst wertvoll für Entwickler, während Sie zunächst eine Anwendung entwickeln, ist es das Speicherabbild debugging-Unterstützung, die Monitorsperre Überprüfung eine überzeugende Ergänzung für die Produktion Diagnosefunktionen in CLR 4 ist.

Tess Ferrandez, eine Microsoft-Supportmitarbeiter hat ein Channel 9 Video (channel9.msdn.com/Posts/Glucose/Hanselminutes-on-9-Debugging-Crash-Dumps-with-Tess-Ferrandez-and-VS2010/) in dem er simuliert eine Sperre Konvoi Szenario üblich, was Sie bei der Behandlung von Kundenanwendungen gefunden hat. Anschließend durchläuft er wie Sie Visual Studio 2010 verwenden, um das Problem zu diagnostizieren. Es ist ein gutes Beispiel für die Typen von Szenarien, die diese neuen Features zu aktivieren.

Jenseits Dumps

Während wir glauben, dass die Tools, die diese Features ermöglichen verringern werden die Zeitspanne, die Entwickler zum Beheben von Problemen in der Produktion benötigt, we weder erwarten (noch möchten) Dump Debuggen, um die einzige Möglichkeit zur Problemdiagnose Produktion sein.

Bei der Diagnose von Problemen der übermäßigen Verwendung Speicherprobleme, beginnen wir normalerweise mit einer Liste von Objektinstanzen gruppiert nach Typ in Anzahl und aggregieren Originalgröße und mit den Fortschritt im Hinblick auf das Objekt Verweis Ketten verstehen. Shuttling von Speicherabbilddateien mit diesen Informationen zwischen Produktions- und Betriebspersonal Entwicklung Maschinen, können Supporttechniker und Entwickler unhandlich und zeitaufwändig sein. Und wie Anwendungen größer werden – dies ist insbesondere mit 64-Bit-Anwendungen verbreitet – die Speicherabbilddateien auch Größe wachsen und bewegen und verarbeiten länger dauern. Es wurde mit diesen allgemeinen Szenarien berücksichtigen, die wir die Profilerstellungs-Features in den folgenden Abschnitten beschriebenen undertook.

Profilerstellungstools

Es gibt eine Reihe von unterschiedlichen Tools integriert, über die CLR des API-Profilerstellung. Szenarien, die im Zusammenhang mit dem der Profilerstellungs-API in der Regel konzentrieren sich auf drei Funktionskategorien unterteilt: Leistung, Arbeitsspeicher und Instrumentation.

Leistung Profilern (wie die, die in einigen Visual Studio-Versionen ausgeliefert wird) den Fokus auf die Sie darüber informiert, wo Code Zeit verbringt. Speicherprofiler konzentrieren sich auf die in der Speicherverbrauch der Anwendung. Instrumentierung Profilern hierzu auch alles andere.

Ich möchte die letzte Anweisung etwas zu verdeutlichen. Eine der Funktionen der Profilerstellungs-API bietet die Möglichkeit zum Einfügen von intermediate Language (IL) ist in verwaltetem Code zur Laufzeit. Wir rufen Sie diesen Code Instrumentation. Kunden verwenden diese Funktionalität, um Tools zu erstellen, die ein breites Spektrum an Szenarien von Codeabdeckung an Fault Injection auf Unternehmensebene Produktion Überwachen von .NET Framework-basierten Anwendungen zu liefern.

Einer der Vorteile die Profilerstellungs-API über die Debug-API hat ist, dass es dient dazu, sehr einfache sein. Beide sind ereignisgesteuerte APIs – beispielsweise in beiden für die Assembly laden Ereignisse vorhanden sind, Thread erstellen, und so weiter ausgelöste Ausnahme –, aber die Profilerstellungs-API, die Sie nur für die Ereignisse registrieren Sie sich kümmern. Darüber hinaus ist die Profilerstellung in den Zielprozess geladen sicherstellen des schnellen Zugriffs auf Zeit Zustand ausgeführt.

Im Gegensatz dazu wird der Debugger-API meldet jedes Ereignis an eine Out-of-Process-Debugger angefügt und unterbricht die Common Language Runtime auf jedes Ereignis. Diese sind nur einige der Gründe, die die Profilerstellungs-API eine interessante Option für die Erstellung von online-Diagnosetools Produktionsumgebungen Zielgruppenadressierung ist.

Profiler anfügen und trennen

Obwohl mehrere Lieferanten immer im Produktions-Anwendungsüberwachung Tools über IL Instrumentation erstellen, haben wir viele Tools, die Nutzung der Einrichtungen und Speicher-Leistungsüberwachung in der Profilerstellungs-API für die reaktive Diagnose-Unterstützung nicht. Die wichtigsten Impediment in diesem Szenario wurde die Unfähigkeit, CLR-Profilerstellung für API-basierter Programme in einer bereits ausgeführten Prozess anfügen.

In Versionen vor CLR-4 überprüft die CLR während des Starts, ob ein Profiler registriert wurde. Wenn Sie einen Profiler eines registrierten findet, wird die CLR geladen und Rückrufe übermittelt, wie angefordert. Die DLL wird nie entladen. Dies ist im Allgemeinen gut, wenn das Tool Auftrag ist eine End-to-End-Bild des Anwendungsverhaltens zu erstellen, es funktioniert jedoch nicht für Probleme, die Sie nicht wussten vorhanden waren, wenn die Anwendung gestartet.

Das am häufigsten mühsam Beispiel dafür ist möglicherweise der Szenario Syntax-Speicherdiagnose. Heute, finden in diesem Szenario wir oft, dass das Muster der Diagnose ist zum Sammeln von mehreren Dumps, betrachten Sie die Unterschiede zwischen den einzelnen in zugewiesenen Typen, erstellen eine Zeitskala der Wachstum und finden Sie im Anwendungscode, wo sind die verdächtigen Typen verwiesen wird. Das Problem ist möglicherweise schlecht Zwischenspeichern Schema implementiert, oder vielleicht werden Ereignishandler in einem Typ Verweise auf einen anderen Typ, der außerhalb des gültigen Bereichs andernfalls halten. Kunden und Mitarbeiter des Supports verbringen viel Zeit, die diese Arten von Problemen zu diagnostizieren.

Zunächst einmal kurz bereits erwähnt, Dumps große Prozesse sind große selbst und für die Diagnose Experte Kennenlernen kann einführen lange Verzögerungen in der Zeit zur Lösung. Außerdem ist das Problem, die Sie ein Experte betreffen in erster Linie aufgrund der Tatsache, dass die Daten nur über eine Windows-Debugger-Erweiterung verfügbar gemacht werden. Es ist keine öffentliche API, ermöglicht Tools zum Verarbeiten der Daten und intuitive Ansichten darüber zu erstellen oder Integration mit anderen Tools, die Analysen unterstützen konnte.

Um die Schwierigkeiten der in diesem Szenario (und andere) zu erleichtern, haben wir eine neue API, die es ermöglicht Profiler an einen laufenden Prozess anfügen und nutzen eine Teilmenge der vorhandenen Profilerstellungs-APIs hinzugefügt. Nach dem Anfügen an den Prozess verfügbaren Sampling zulassen (Siehe “ VS 2010: Anfügen des Profilers zu einer verwalteten Anwendung ” zur Blogs.msdn.com/Profiler/Archive/2009/12/07/vs2010-Attaching-the-Profiler-to-a-Managed-Application.aspx) und Speicherdiagnose: Durchlaufen des Stapels; Zuordnen von Adressen-Funktion, um symbolische Namen; die meisten der Garbage Collector (GC)-Rückrufe und Inspection-Objekts.

Im Szenario beschriebenen können Programme diese Funktionen ermöglichen Kunden Anfügen an eine Anwendung zu einer übermäßigen Speicherauslastung Wachstum oder langsame Antwortzeiten auftreten, zu verstehen, was wird derzeit ausgeführt und wissen, welche Typen auf dem verwalteten Heap aktiv sind und was ist das regelmäßige Aktualisieren Sie aktiv nutzen. Nach dem Sammeln der Informationen Sie das Tool trennen können und die CLR Profiler-DLL entladen wird. Während der Rest des Workflows ähneln – suchen, in denen diese Typen verwiesen wird, oder im Code erstellt – wir davon ausgehen, dass Programme dieser Art einer anpassbaren Auswirkungen auf die Mittelwert-Zeit-zu-Auflösung für diese Probleme haben. Dave Broman, Entwickler in der CLR-API, die Profilerstellung wird dieser und anderen Profilerstellung Funktionen ausführlicher in seinem Blog ( erläutert.Blogs.msdn.com/davbr).

Ich möchten jedoch zwei Einschränkungen explizit in diesem Artikel hervorzuheben. Erstens Speicherdiagnose auf Anfügen ist nicht gleichzeitige (oder blockieren) GC-Modi auf: der GC hält bei Ausführung des gesamten verwalteten Code beim Ausführen einer Garbage Collection. Wird während der gleichzeitigen GC der Standardwert ist, verwendet ASP.NET Servermodus GC, einen nicht parallelen Modus. Dies ist die Umgebung, in denen wir die meisten dieser Probleme finden Sie unter. Wir danken Ihnen für die Nützlichkeit von Anhängen-Profilerstellung Diagnosen für Clientanwendungen und davon ausgehen, dass dies in einer zukünftigen Veröffentlichung übermitteln. Wir werden einfach den häufigeren Fall für CLR-4 priorisiert.

Zweitens: Sie sind nicht in der Lage, verwenden Sie die Profilerstellungs-API zu instrumentierenden IL nach dem Anfügen. Diese Funktion ist besonders wichtig, unser Unternehmen Überwachung Tool Vertragspartner in der Lage sein, um Ihre Instrumentation dynamisch als Reaktion auf Laufzeitbedingungen ändern möchten. Wir bezeichnen häufig diese Funktion als erneutes JIT. Heute stehen Ihnen eine Möglichkeit, den IL-Hauptteil einer Methode zu ändern: Wenn es zunächst JIT-kompiliert wird. Wir erwarten austreten AW-JIT eine erhebliche und wichtige Unterfangen sein und aktiv Prüfen der Kunden und die technischen Auswirkungen wie wir betrachten, übermitteln die Arbeit in einer zukünftigen Version.

Registrierung ohne Aktivierung für Profiler

Profiler anfügen und die unterstützende Arbeit nach bestimmten Profilerstellungs-APIs zu aktivieren, fügen die größte Arbeitskomponente wir in der CLR wurde für CLR-4-API die Profilerstellung wurde. Aber wir sind entzückt, um ein weiteres Feature sehr kleines (hinsichtlich der Verfahrenstechnik-Kosten) zu suchen, das eine erstaunlich große Auswirkungen auf Kunden, die Erstellung von Tools für die Produktion-Klasse hat.

Vor der CLR-4 für ein Tool zum Abrufen der Profiler-DLL geladen in einer verwalteten Anwendung, die zwei wichtigen Teile der Konfigurationsinformationen erstellt wurde. Die erste wurde ein Paar von Umgebungsvariablen, die zum Aktivieren der Profilerstellung die CLR mitgeteilt und welche Profiler-Implementierung (die CLSID oder ProgID) geladen werden beim Starten der CLR einrichten. Angesichts der Tatsache, dass die Profiler-DLLs werden als in-Process-COM-Servern (mit der CLR wird der Client) implementiert, wurde der zweite Teil der Konfigurationsdaten der entsprechenden COM-Registrierungsinformationen in der Registrierung gespeichert. Dies im Wesentlichen die Laufzeit, mithilfe von COM, mitgeteilt, wo sich die DLL auf dem Datenträger.

Bei der Planung von CLR 4 beim Versuch, zu verstehen, wie wir für Kreditoren zu Produktions-Klasse Buildtools erleichtern konnte mussten wir einige interessanten Unterhaltungen mit einigen unsere Support-Techniker und Tools Kreditoren. Das Feedback, wir erhalten, wurde, dass bei einem Anwendungsfehler in der Produktion, Kunden häufig weniger Informationen zu Auswirkungen der Anwendung sorgt (es ist bereits fehl; Sie möchten die Diagnoseinformationen zu erhalten und zu verschieben) und Weitere Informationen zu Auswirkungen auf den Zustand des Computers. Viele Kunden wechseln, um großartige Längen zu dokumentieren und die Konfiguration von Ihren Computern bespitzeln und Einführen von Änderungen an dieser Konfiguration kann Risiko vorzustellen.

Daher soll in Bezug auf die CLR-Teil der Lösung, es ermöglichen aktivieren Xcopy bereitzustellenden Diagnostics Tools, um beide das Risiko von Statusänderungen und minimiert um die Zeit zu reduzieren, die es, dauert um die Tools zu erhalten, bis und Ausführung auf dem Computer.

In CLR 4 entfernt wir die Notwendigkeit, den COM-Profiler-DLL in der Registrierung zu registrieren. Wir benötigen noch Umgebungsvariablen, wenn Sie Ihre Anwendung unter dem Profiler starten möchten, das in den Anhängen Szenarien zuvor besteht jedoch keine Konfiguration erforderlich. Ein tool einfach Aufrufe fügen Sie die neue API, übergibt der Pfad zu der DLL und der CLR lädt den Profiler. Nach vorne verschieben, suchen wir in Möglichkeiten zur weiteren Vereinfachung der Konfiguration der Profiler wie Kunden weiterhin die Umgebungsvariable Lösung in einigen Fällen eine schwierige Aufgabe finden.

Kombiniert, aktivieren die zwei Profilerstellungs-Features, die soeben erläuterten eine Klasse von geringem Aufwand-Tools, die Kunden bei der unerwartete Fehler schnell bereitstellen auf einem Produktions Computer zum Sammeln von Leistungs- oder Speicher Diagnoseinformationen zum Ermitteln der Ursache des Problems helfen können. Anschließend kann genauso schnell der Benutzer den Computer in seinen ursprünglichen Zustand zurück.

Zusammenfassung

Arbeit an Features für die Diagnose für die CLR ist bittersweet. Viele Beispiele für wie viele Kunden bestimmte Probleme kämpfen angezeigt, und noch vorhanden ist immer coole arbeiten wir tun können, mit denen einfache Entwicklung und Kunden leichter machen. Wenn die Liste der Probleme, die unsere Kunden schwierig ändern ist nicht – d. h., sind wir Elemente nicht daraus entfernen, dann wir nicht erfolgreich sind.

In CLR 4 meiner Meinung nach wir Features integriert, die nicht nur sofortigen Wert bei der Adressierung der häufigsten Probleme bereitzustellen, sondern auch eine Grundlage Layout, auf der wir fortgesetzt werden kann, in der Zukunft zu erstellen. Nach vorne verschieben, werden wir weiterhin investieren in APIs und Dienste, mit denen Sie sogar noch einfacher, sinnvolle Diagnoseinformationen in allen Phasen des Lebenszyklus einer Anwendung verfügbar zu machen, so dass Sie mehr Zeit zum Erstellen von neuen Features für Ihre Kunden und weniger Zeit, die vorhandene Debuggen konzentrieren können.

Wenn Sie Feedback uns auf Diagnose-Arbeit, die wir für unsere nächste Version berücksichtigt sind interessierende, haben wir eine Umfrage unter gebucht.surveymonkey.com/s/Developer-Productivity-Survey. Wie wir jetzt über das Schiff CLR 4 sind, sind wir viele unserer Zeit zur Planung für zukünftige Versionen konzentrieren und Daten aus der Umfrage werden helfen Sie uns, unsere Bemühungen zu priorisieren. Wenn Sie ein paar Minuten Zeit haben, würden wir lieben, von Ihnen zu hören.

Jon Langdon ist Programmmanager im CLR-Team, wo er auf Diagnose konzentriert. Vor war verknüpfen das CLR-Team, er als Berater bei Microsoft Services hilft Kunden, diagnostizieren und Beheben von Problemen mit umfangreichen, Unternehmensanwendungen.

Dank an den folgenden technischen Experten für die Überprüfung dieses Artikels: Rick Byers