Archive for the ‘Debugging’ Category

Für Powershell .Net Framework Tracing aktivieren

13 Dezember 2014

Manchmal ist nicht klar warum etwas nicht funktioniert. Da Powershell stark auf das .Net Framework angewiesen ist, kann man auch dessen Trace-Möglichkeiten nutzen, um eine tiefergehende Fehleranalyse zu ermöglichen. Hilfreich ist das Tracing z. B. in Verbindung mit der Netzwerkkommunikation.

Unter .Net kann man das Netzwerktracing wie in diesem Artikel beschrieben aktivieren: http://msdn.microsoft.com/en-us/library/ty48b824(v=vs.110).aspx. Damit der Trace-Mitschnitt in Powershell aktiviert werden kann, muss die in der betreffenden Powershellversion die Datei Powershell.exe.config angelegt, bzw. bearbeitet werden. Dabei ist von Bedeutung, ob man mit Powershell 32-Bit oder 64-Bit arbeitet. Zum Thema Powershell 32-/64-Bit siehe hier: http://newyear2006.wordpress.com/2012/06/20/prfen-ob-eine-powershell-sitzung-in-einer-32bit-oder-64bit-prozess-umgebung-luft/.

Kurz: Unter einem 64-Bit System findet man die 64-Bit Powershell-Version unter C:\WINDOWS\SYSTEM32\WINDOWSPOWERSHELL\V1.0 und die 32-Bit Powershell-Version unter C:\WINDOWS\SYSWOW64\WINDOWSPOWERSHELL\V1.0. Auf einem reinen 32-Bit-System ist der Pfad wieder wie bei der 64-Bit Fassung.

Wenn man nun also seine Powershell.exe.config, die so aussieht

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

   <system.diagnostics>

        <sources>

            <source name="System.Net">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

            <source name="System.Net.Sockets">

                <listeners>

                    <add name="System.Net"/>

                </listeners>

            </source>

        </sources>

        <switches>

            <add name="System.Net" value="Verbose" />

            <add name="System.Net.Sockets" value="Verbose" />

        </switches>

        <sharedListeners>

            <add name="System.Net"

                type="System.Diagnostics.TextWriterTraceListener"

                initializeData="System.Net.log"

                />

        </sharedListeners>

        <trace autoflush="true" />

    </system.diagnostics>

</configuration>

im Verzeichnis C:\Windows\System32\WindowsPowershell\V1.0\ angelegt hat, kann man anschließend Powershell starten. Wichtig, die Einstellungen wirken sich erst aus, wenn eine neue Powershell.exe gestartet wird.

Man bekommt nun in der Datei System.Net.Log die Trace-Daten gespeichert. Die System.Net.Log wird in dem Verzeichnis der Powershell.exe gespeichert.

Möchte man die Trace-Möglichkeit in Powershell-ISE nutzen, muss man natürlich die Datei Powershell_ise.exe.config bearbeiten.

Das Format der Trace-Daten ist kurz hier angerissen: http://msdn.microsoft.com/en-us/library/46fcs6sz(v=vs.110).aspx.

Tschüss Microsoft Netzwerkmonitor (NetMon), willkommen MessageAnalyzer!

26 Oktober 2012

Endlich geht es voran mit der neuen Version des Microsoft Netzwerkmonitors. Aber nicht einfach eine Nachfolgeversion mit erweiterten und angepassten NPL-Dateien für Windows 8 und Server 2012 erscheint sondern eine komplett überarbeitete Version. Dies trägt vor allem dem Umstand Rechnung, dass der NetMon nicht nur für Netzwerkpakete sondern mittlerweile für alle möglichen Protokolle in Microsoft Systemen vorgesehen ist. Sei es Exchange, Sharepoint, SMB, NDIS, USB oder Systemereignisse bei allem kann man NetMon und in Zukunft den MessageAnalyzer einsetzen.

Hier ein paar Artikel, welche verdeutlichen was mit der alten Version bereits möglich war: http://newyear2006.wordpress.com/2012/07/06/mitschneiden-von-netzwerkverkehr-am-virtuellen-switch-eines-hyper-v-version-3-servers/, http://newyear2006.wordpress.com/2009/12/27/usb-probleme-in-windows-7-analysieren-und-verstehen/ und http://newyear2006.wordpress.com/2009/08/26/netzwerkprobleme-unter-windows-7-analysieren/.

Durch die neue Version werden nun automatisch alle aktuellen Protokolle unterstützt und darüberhinaus sind jede Menge sinnvolle neue Funktionen enthalten.

Blog: http://blogs.technet.com/b/messageanalyzer/

Minidump Crashdump Analyse unter Windows XP bis Server 2008 R2

29 September 2011

Ein Thema das keiner liebt aber sicher fast jeden mit einem Bluescreen schon mal gegrüßt hat sind die Abstürze wenn Treiber versagen. Aus aktuellem Anlass hier mal ein paar Links wo man zuerst Infos zum Thema bekommt, und was man wie einstellen kann: http://support.microsoft.com/kb/254649

Die Minidump werden unter %SystemRoot%\Minidump gespeichert, also in der Regel unter C:\WINDOWS\Minidump. Was macht man dann aber mit so einer Datei? Hier wirds beschrieben: http://support.microsoft.com/kb/315263/en-us

Hier gibts die nötigen Debugging Tools: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Happy Debugging!

Standarddienste auf Small Business Server

21 Juli 2011

Um bei Problemen mit einem Small Business Server schneller prüfen zu können woran ein Problem liegt, ist es natürlich hilfreich zu wissen welche Dienste normalerweise laufen.

Hier für SBS 2011: http://blogs.technet.com/b/sbs/archive/2011/07/13/default-services-and-their-status-in-sbs-2011.aspx

für SBS 2008:
http://msmvps.com/blogs/bradley/archive/2009/06/05/default-sbs-2008-running-services.aspx

und für 2003:
http://support.microsoft.com/kb/829623

Wenn man noch weitere Infos über Dienste erfahren möchte, ist folgendes noch interessant:
http://newyear2006.wordpress.com/2011/04/28/bersicht-und-beschreibungen-ins-detail-ber-dienste-in-windows-systemen/

Übersicht und Beschreibungen ins Detail über Dienste in Windows Systemen

28 April 2011

Vom alten Windows XP 32Bit ohne Service Pack bis Windows 7 64Bit mit Service Pack 1 werden alle möglichen Dienste sehr detailliert beschrieben. Zugleich findet man Vergleiche welche Dienste auf welcher SKU aktiviert sind. Man findet mögliche Alternativen um mit weniger Resourcen auszukommen.

Einfach genial. Fragt man sich warum MS dann nicht hinbekommt. Nicht einmal im Resource Kit gibt es eine so umfangreiche Auflistung der Dienste, deren Abhängigkeiten sowie Beschreibungen.

http://www.blackviper.com/wiki/Main_Page

Outlook 2010 Logging

19 April 2011

Interessanter KB-Artikel, wo und was Outlook 2010 alles mitloggen kann: http://support.microsoft.com/kb/2498869

E-Mail Header Zeilen Analysieren

19 Januar 2011

Bei Problemen ist es hilfreich, wenn man weiß wo man nachschauen kann und wo es weitere Infos gibt. Beim letzten Problem mit den Umlauten in Outlook http://newyear2006.wordpress.com/2011/01/18/outlook-problem-mit-umlauten-anstatt-werden-weie-fragezeichen-in-schwarzen-rauten/ stellte sich hin und wieder die Frage was der einzelne Eintrag im E-Mail-Header was für eine Bedeutung hat. Bestimmte Standardeinträge sind klar, aber nicht die Erweiterungen wo von verschiedenen Programmen eingetragen werden. Ebenso stellt sich oft die Frage, wo der betreffende Webmailer oder das E-Mail-Programm die Headerinformationen versteckt hält.

Eine gute Seite mit vielen Infos zu diesen Themen ist diese: http://th-h.de/faq/headerfaq.php

Wireshark Anzeigefilter per Kommandozeile mitgeben

2 Januar 2011

Für bestimmte Auswertungen kann es ganz interessant sein bei Wireshark den zu verwendenden Anzeigefilter per Kommandozeile mitzugeben.

Beispiel:

wireshark –r inputfile.pcap –R "ip.dst == 74.208.164.166"

Im obigen Beispiel wird z. B. die IP-Adresse eines sinkhole von Shadowserver.org angegeben. Allerdings stehen einem dann die restlichen Pakete aus inputfile.pcap nicht zur Verfügung, somit reagiert –R nicht als Anzeigefilter sondern gleich als Lesefilter.

Aber für den schnellen Blick, ob bestimmte Pakete enthalten sind oder nicht sicherlich sinnvoll.

Windows Firewall LOG-Datei PFirewall.LOG per Powershell analysieren

21 November 2010

Aufgrund des genialen Formats der pfirewall.log-Datei hier ein Einzeiler für Powershell, damit man die entscheidenden DROPs nicht verpasst:

$sr = New-Object System.IO.StreamReader ("pfirewall.log"); while (($line = $sr.ReadLine()) -ne $null) {if ($line -match "DROP") {Write-Host -fore Red $line} else {Write-Host $line}}; $sr.Dispose()

Drops werden nun immer in roter Farbe dargestellt.

Da die Methode die Logdatei Zeilenweise ausließt geht alles ganz flott und funktioniert auch mit riesengroßen Dateien.

Hier eine Variante vom Scripting Guy der mehr auf Details in der Log eingeht: http://blogs.technet.com/b/heyscriptingguy/archive/2009/04/16/how-can-i-parse-my-firewall-log-file-to-see-what-kind-of-packets-are-being-sent.aspx

Probleme mit Druckertreibern und Windows 7 und Server 2008 R2 lösen

17 November 2010

Wem ein schlecht programmierter Druckertreiber mit zu vielen unnützen Funktionen das Leben schwer macht und regelmäßig die Druckerwarteschlange runterzieht, der wird sich über die Möglichkeit der Druckertreiberisolation freuen:

http://blogs.technet.com/b/askperf/archive/2009/10/08/windows-7-windows-server-2008-r2-print-driver-isolation.aspx

Damit hat jeder Treiber seinen eigenen Prozess und kann sich darin austoben. Ein Crash sorgt dann nur davon dass die betreffende PrintIsolationHost.EXE abstürzt.

Hier noch einige Interessante Infos von HP und deren UPD mit Isolated Unterstützung: http://h20338.www2.hp.com/hpsub/downloads/
UPD_Microsoft_Driver_Isolation_Mode.pdf


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.