Archive for the ‘Debugging’ Category

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

Windows Firewall mit Erweiterter Sicherheit debuggen von DROP Paketen

12 November 2010

Wenn es mal wieder nicht klappt mit dem Zugriff von einem entfernten Rechner auf Netzwerkressourcen könnte es an der Windows Firewall liegen. Vorhanden ab Windows Vista.

Zuerst muss man mal rausfinden ob dem so ist.

Man startet also die Windows Firewall mit erweiterter Sicherheit (WF.MSC).

Dort schaut man dann zuerst welches Profil aktuell aktiv ist und klickt dann auf “Windows-Firewalleigenschaften” oder man klickt links im Baum auf den obersten Eintrag mit der rechten Maustaste und geht auf Eigenschaften.

Es öffnet sich ein Dialog mit Registern für jedes Profil. Hier klickt man nun auf das aktuell aktive Profil. Nun kann man bei Protokollierung durch klick auf Anpassen den Pfad sowie die Einstellungen dafür verändern.

Hier sollte man sich nun mindestens den Pfad für die Logdatei merken und die Protokollierung von verworfenen Paketen aktivieren. Der vorgebene Pfad lautet:

C:\Windows\system32\LogFiles\Firewall\pfirewall.log

Nun werden die verworfenen Pakete in der LOG-Datei gespeichert, allerdings muss man teilweise ein paar Sekunden warten bis die Daten in der LOG-Datei auftauchen.

Verworfene Pakete sehen dann so aus:

2010-11-12 18:44:51 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – – – RECEIVE
2010-11-12 18:45:07 DROP TCP 192.168.10.22 192.168.10.20 54745 8624 48 S 1684385589 0 65535 – – – RECEIVE
2010-11-12 18:47:47 DROP TCP 192.168.10.22 192.168.10.20 54747 8624 64 S 1346924637 0 65535 – – – RECEIVE

Tolle Sache. Hier die Beschreibung des Formats: http://technet.microsoft.com/en-us/library/cc753781(v=WS.10).aspx. Aber den Grund warum die Pakete verworfen wurden, der wird einem nicht mitgeteilt.

OK, als erstes sollte man auf dem betreffenden Server Rechner erst prüfen ob die betreffende Serveranwendung überhaupt läuft:

netstat –an

hilft. Dort sollte bei der lokalen Adresse 0.0.0.0 mit dem passenden Port stehen und der Status sollte ABHÖREN lauten.

Tiefergehende Infos bekommst man als Admin mittels

netstat –p TCP –abn

Dann werden die Prozesse angezeigt ebenso findet eine Einschränkung des Protokolls auf TCPv4 statt.

Mittels Event Tracing kann man das Spiel nun weiter treiben und noch tiefer schauen. Das Event Tracing ist eine ziemlich mächtige Sache. Hier bin ich schon mal darauf eingegangen in Verbindung mit USB: http://newyear2006.wordpress.com/2009/12/27/usb-probleme-in-windows-7-analysieren-und-verstehen/

Man kann sich tiefergehende Infos mittels netsh mitschneiden. Dazu startet man

netsh wfp

Dieser Befehl startet die Netzwerkshell und wechselt zum WFP Kontext welcher für Windows-Filter-Platform steht, welche für das inspizieren der Pakete zuständig ist.

Hier kann man nun das Aufzeichnen von Paketen mittels

capture start

aktivieren. Alle Pakete die nun empfangen werden, werden nun gespeichert und in die Datei WFPDiag.CAB im aktuellen Verzeichnis abgelegt wenn man den Befehl

capture stop

eingibt.

Die Datei WFPDiag.CAB enthält dann zwei Dateien die WFPDiag.ETL und WFPDiag.XML. Die XML-Datei kann man sich dann direkt anschauen und findet so interessante Einträge wie:

- <netEvent>
- <header>
  <timeStamp>2010-11-12T16:03:08.836Z</timeStamp>

- <flags numItems="8">
  <item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>

  <item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>

  <item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>

  <item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>

  </flags>

  <ipVersion>FWP_IP_VERSION_V4</ipVersion>

  <ipProtocol>6</ipProtocol>

  <localAddrV4>192.168.10.20</localAddrV4>

  <remoteAddrV4>192.168.10.22</remoteAddrV4>

  <localPort>8624</localPort>

  <remotePort>54619</remotePort>

  <scopeId>0</scopeId>

- <appId>
  <data>530079007300740065006d000000</data>

  <asString>S.y.s.t.e.m…</asString>

  </appId>

  <userId>S-1-5-18</userId>

  </header>

  <type>FWPM_NET_EVENT_TYPE_CLASSIFY_DROP</type>

- <classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

  </netEvent>

Ist leider etwas unformatiert. Aber hier finden sich die gesuchten Informationen wieder: Die IP-Adresse des anfragenden Computers 192.168.10.22 und die des lokalen Computers mit 192.168.10.20 wo Port 8624 angesprochen werden soll.

Der Zweig mit ClassifyDrop enthält noch weitere Hinweise:

- <classifyDrop>
  <filterId>74004</filterId>

  <layerId>44</layerId>

  <reauthReason>0</reauthReason>

  <originalProfile>2</originalProfile>

  <currentProfile>2</currentProfile>

  </classifyDrop>

Die Struktur wird in http://msdn.microsoft.com/en-us/library/ee707311(v=VS.85).aspx näher erläutert.

Entscheidend ist die LayerID 44  welche auf FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 weiter oben in der XML-Datei zeigt. Übersicht der Filter: http://msdn.microsoft.com/en-us/library/aa366492(v=VS.85).aspx

Manchmal kann es helfen so tief ins System Einblick zu bekommen. Im konkreten Fall brachte es aber nichts. Erst als anstatt IIEXPRESS.EXE explizit der zugehörige Port 8624 per neuer Firewallregel geöffnet wurde, hat es funktioniert.

Den einen oder anderen Hinweis für die Innereien der Filterplattform findet man auch im Entwicklerforum: http://social.msdn.microsoft.com/forums/en-US/wfp/threads/


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.