Mikael Deurell : Debugging

Fix till adplus på Windows7

mikaeld — Wed, 11 Feb 2009 16:04:00 GMT

Min övergång till Windows7 har gått hur bra som helst. Det har bara varit två hangups som jag inte riktigt snyggt har kommit runt. Det ena är att adplus vägrar att hitta aktuella processer när jag skall ta ut en dump och den andra är att registreringar av WMI providers inte fungerar som jag skulle vilja. WMI sparar jag ett litet tag till, men adplus visar sig ha en ganska enkel lösning.

Problemet ligger i tlist som används av adplus för att hitta aktuell process. Den enkla lösningen är att skicka med en -tlist switch till adplus men det är lite att gräva ner huvudet i sanden. Gräver man lite djupare (som John Robbins gjorde) så finner man att i Windows 7 lägger till en extra [0] i output, såhär;

[0] 1 32 5828 powershell.exe
Command Line: ...

denna finns inte under Vista vilket gör att parsningen av processerna inte längre funkar och genererar en:

>adplus -hang –p 4242 -o c:\dumps
Microsoft (R) Windows Script Host Version 5.8
Copyright (C) Microsoft Corporation. All rights reserved.

The following requested processes are not executing:
4242;

Annoying... Men vår hjälte har givetvis skapat en fix för detta som ni kan hitta här.

Tack till Tess som tipsade min om detta! Nu är världen vacker igen...

Happy debugging´on Windows7!

SOS/SOSEX kommandon från dagens MSDN Live

mikaeld — Wed, 05 Nov 2008 22:50:00 GMT

För er som var på min debugging session på MSDN Live i veckan kommer här en sammanställning av alla de kommandon i WinDbg (SOS/SOSEX) jag använde. Håll tillgodo mina debuggingvänner! :-)

Ta ut en hang dump med adplus
adplus -hang -p <numberofprocess> -o c:\hangs -quiet

Starta windbg
windbg -z pathtodump

Ladda sos/sosex extension för .net debuggning
.loadby sos mscorwks
.load pathtososex.dll

Kolla alla stackar
managed
~* e !clrstack
native
~* kb
combined
~* e !dumpstack

Kolla locks, syncobjects
!SyncBlk

Deadlocks
!dlk

Byt till tråd n
~ns

Starta cmdtree med "meny" med vanliga sos/sosex-kommandon
.cmdtree c:\debugging\cmdtree.txt
(innehåll till cmdtree.txt kan laddas ner från John Robbins lysande blog)

Hämta time info
.time

Thread time
!runaway

Visa threadpool info
!threadpool

Visa managed heap stat
!dumpheap -stat

Dumpa Large Object Heap (objekt över 85k)
!dumpheap -min 85000 (sos)
!dumpgen 3 (sosex)

Visa valt objekt
!do 00000001e60bcdd0

Debugga i produktion eller testa bort i utvecklingsfas?

mikaeld — Tue, 30 Sep 2008 13:26:00 GMT

Enkelt svar hoppas jag... Jag tänkte visa ett exempel på hur ni kan debugga en låg cpu hängning i asp.net med hjälp av WinDbg. Jag är långt ifrån någon mästare i WinDbg men jag har grym nytta av mina debuggingkunskaper i egenskap av Solution Architect. Hela meningen med del 1 i denna screencast är att visa hur man kan debugga en hängning i produktion för att sedan i del 2 visa hur ni kan testa bort denna avvikelse med hjälp av Visual Studio Team System Test Edition (VSTEST).

Screencasts finns på Channel9 och ni har länkar till de två delarna nedan;

Del 1 - Debugga låg cpu hang i asp.net med WinDbg
Del 2 - %#& i att spendera tid i WinDbg och testa bort avvikelsen med VSTEST

Applikationen jag använder som bas i dessa screencasts är utvecklad av Tess Ferrandez och visar en hel del vanligt förekommande avvikelser. Lysande för att vässa era debugging och testkunskaper! Kan ni designa tester för att fånga samtliga avvikelser? Kan ni använda denna kunskap för att inte designa in dessa i er nästa arkitektur? Så klart ni kan... Öva, öva, öva! :-)

I used to rule the world
Seas would rise when I gave the word
Now in the morning I sleep alone
Sweep the streets I used to own...

Använd Powershell för att se om du kompilerat med debug build i prod

mikaeld — Tue, 02 Sep 2008 18:14:50 GMT

Debug är debug och prod är prod… Så varför har vi en massa assemblies i produktion som kompilerats med debug attribut? Vore det inte bra att kunna köra en batchkörning på alla assemblies i prod för att se om någon slarvat? Såklart ni vill! :-) Har ni powershell? Sweet!

Man tycker kanske att det skulle räcka med att kolla en;

[System.Diagnostics.DebuggableAttribute]::GetCustomAttribute($loadedAssembly, [System.Type]::GetType("System.Diagnostics.DebuggableAttribute"))

för att se om vi slängt på ett debug attribut… En enkel $null check borde vara nog… Men… Det funkar med vb compilern (vem som nu använder den ), men c# compilern slänger alltid in ett debug attribut (även i release build) vilket gör att vi får gå vidare med…

Att kolla in DebuggingFlags… Yay!

function get-debugmode([string] $nameOfAssembly)
{
$loadedAssembly = [System.Reflection.Assembly]::Loadfile($nameOfAssembly, $null)
$debugAttribute = [System.Diagnostics.DebuggableAttribute]::GetCustomAttribute($loadedAssembly, [System.Type]::GetType("System.Diagnostics.DebuggableAttribute"))
$debugAttribute
}

Detta är ett utmärkt sätt för IT-Pros att få köra en härlig “blame-safari”/förbrödring på dev sidan och samtidigt får upp kvaliteten på det ni kör i produktion!

Remember me when you're the one who's silver screened
Remember me when you're the one you always dreamed
Remember me whenever noses start to bleed
Remember me, special needs…

Enkel w3wp->application pool mappning

mikaeld — Tue, 02 Sep 2008 12:01:03 GMT

Någonting har hänt och du skall snabbt leta reda reda på rätt w3wp process för den app pool som du så vackert konfigurerat upp… Men vilken av alla 1000 w3wp processer är det?

Det enklaste är väl att köra tlist.exe som kommer med debugging tools for windows, vilket producerar följande:

>tlist w3wp

Men, vore det inte kallare att göra det i Powershell? Det mest logiska vore att köra en get-process w3wp, men vi vill få fram information om commandline för att greppa vilken app pool som är aktuell… Och den finns inte här… Men… Kör med WMI istället så är vi hemma:

>Get-WmiObject Win32_Process | Where-Object { $_.processname -eq "w3wp.exe" } | fl -property processname, commandline, processid

Och konvertera till en funktion i powershell:

function get-w3wpinfo()
{
Get-WmiObject Win32_Process | where{$_.Name -eq "w3wp.exe"}
}

>get-w3wpinfo | Format-List -property processid, commandline

Hemma… :-)

You choose you chose
Poetry over prose…

Sjukt bra debuglabbar med Tess Ferrandez!

mikaeld — Mon, 04 Feb 2008 20:43:00 GMT

Tess Ferrandez har skapat en serie med labbar där hon presenterar vanliga post mortem debugging scenarios. Hon har byggt ihop en sjukt bugging applikation (BuggyBits) som innehåller vanliga fel som vi upptäcker i produktionsmiljö. Till detta beskriver hon de steg som krävs för att reproducera, ta en dump och felsöka. Du hittar allt här! I vanlig Tessanda är det magiskt bra! Apropå Tess, sprang på henne i fikarummet idag och som alltid spårar samtalen ur till att täcka allt från WinDbg till bandvagnsåkning till fondygrytor, hur man åker med barn i knapplift och magdans... Trevligt... Tess huserar på GTSC, vår supportorganisation som fått mig att se support i ett helt nytt ljus. Så många ruggigt begåvade, sociala och trevliga människor samlade på ett ställe... Och de är nästan osynliga för folk utanför huset... Konstigt...

Metoder för att fixa buggar

mikaeld — Sat, 22 Sep 2007 23:04:00 GMT

Ok, sedan jag började få betalt för att gräva i andra människors produktionskod för att fixa buggar jag inte själv skapat, har jag fått lov att förfina mina debuggingmetoder en aning. Det visar sig att de flesta bolag verkar tillämpa någon av följande för att strukturera sin avlusning (både i utveckling och produktion)

Intuition
Ok, har du skrivit koden själv och har 100% koll (vem har det?), så är det inte ovanligt att du har en såndär härlig magkänsla av vad det är som inte fungerar. Bra vid fulutveckling... Men... Denna metakunskap följer oftast inte med när utvecklaren slänger över ett installationspaket till operations och en kille i Birkenstock tar över. Inte alltför sällan leder denna approach till katastrof då att den slutsats man drog var felaktig från början...
Skippa!

Diagnostics
Detta bygger på att vårt kära debugging-offer emitterar tillräckligt med information för att vi skall kunna diagnostisera och mäta. Inte helt vanligt. Av någon anledning är debug, trace eller perf-counters inte vanligt förekommande i produktionskod. Fattar inte varför... Känns som om detta fått en fulstämpel på sig av någon anledning. Tron på att allt skall fixa sig för att man har code coverage på några lama unittester verkar regera på många ställen... Synd...
Inkludera alltid en verbose switch för Trace och använd den!
Inkludera perf-counters för viktiga objekt
Etablera en Health Model (en hälso state machine) för applikationen redan i första iterationen.

"Leap Of Faith"
Ändra på något... Kolla om buggen försvinner... Repetera... Känns (helt allvarligt) som den vanligaste metoden därute...
Acceptera att detta är vanligt förkommande när någon annan kommer att felsöka din kod! Bli en av dem som lämnar träsket!

"Head In Sand" eller Strutsen
Hävda att det är ett specialfall som inte kommer att inträffa i "verkligheten", bli defensiv och försvara dig med näbbar och klor.

"Scientific Approach"
- Samla in information
- Analysera data
- Kicka fram en hypotes (och skriv ner!)
- Testa hypotesen (Våga inte ens tänka på att starta Visual Studio eller WinDbg och bränna tid innan ni nått hit)
- Upprepa

Jag blir alltid fundersam över driftsorganisationer och utvecklingsavdelningar som börjar skrika MINNESLÄCKAGE! och skicka iväg incidentrapporter, eskalera ärenden till problem managers utan att ens ha gjort ett försök till att använda den sistnämda metoden. Att etablera en process för hur en outsourcad driftsavdelning skall samla in data, analysera denna och kicka fram en hypotes borde vara insprängt i det kontrakt som etableras innan driftssättning. I detta dokument borde även definitioner på minnesläckage, bug, hög minnesanvändning, hang, crash och annat ingå. Annat jag skulle vilja se här är en lista på verktyg (adplus, WinDbg, DebugDiag) och hur dessa skall användas. Tänk vad mycket tid vi skulle vinna... Och vad mycket pengar vi skulle tjäna...

Skall vi köra in i GDIProcessHandeQuota-väggen?

mikaeld — Mon, 11 Jun 2007 17:54:00 GMT

Sprang på ett intressant case häromdagen. En applikation använder ett mycket stort antal GDI objekt och helt plötsligt ger appen upp och vi springer in i väggen! Varför? Det är inte helt konstigt att moderna appar som körs på burkar med två, tre skärmar eller plasmaväggar gör att vi kan slänga upp mer stuff att fylla ytan med. Det underbara är att detta gör att nya härliga "features" poppar upp till ytan...

Problemet:
Applikationen kör på en kanonstor skärm och när vi allokerar fler än 10000 GDI-objekt i den aktulla processen springer vi in i väggen.

Förklaring:
Väggen vi springer in i är en gräns som specas under GDIProcessHandeQuota i registryt (default 10000). GDI objekt stödjer bara ett handle per objekt och handles till GDI-objekt är privata för aktuell process. Den teoretiska gränsen är 65536 ($10000) GDI-handles per session, men i de flesta fall är gränsen givetvis lägre (beroende på hur mycket minne som finns tillgängligt).

Så de officiella gränserna är:
Windows 2000 -> 16384
Windows XP -> 65536
Windows 2003 -> 65536

Lösning:

Var inte rädd för att kränga upp GDIProcessHandeQuota om den inte räcker till, men glöm inte att testa, testa och testa för att se hur prestandan påverkas. I detta fall räckte det att hysta upp denna till 30000 och allt fungerade fint.

ps/
Tänk på att aktuell burk kan börja gå på knäna, särskilt om vi kör andra grafikintensiva program samtidigt...

officiell info här: http://msdn2.microsoft.com/en-us/library/ms724291.aspx

Ännu ett projekt som XMLSerialiserar sig till Out-Of-Memory...

mikaeld — Fri, 23 Mar 2007 14:38:00 GMT

Igår var jag inne och debuggade en dump från ett projekt där man hade problem med en w3wp process som "åt minne". Efter att ha kickat igång WinDbg och kört en .dumpdomain som resulterade i att 2600 dynamiskt skapade assemblies matrixade förbi på skärmen samtidigt som loggarna skvallrade lite om XmlSerializer misstänkte jag givetvis en klassisk http://blogs.msdn.com/tess/archive/2006/02/15/532804.aspx. Och mycket riktigt fixade detta kakan. Tror detta är fjärde eller femte gången jag fixar en issue bundet till detta... Efter lite applåder och hallabaloo fick jag ett snällt mail från en av utvecklarna i projektet (tillika en gammal trevlig kollega från konsulttiden innan Microsoft) med en fråga om hur kan man lära sig att debugga produktionskod? Skrev ett litet svar, kanske någon mer som är intresserad... :-)

Gott! Jag misstänkte det... :-) Självklart har jag en hel del tips och tricks kring debugging! Ett tips är att öva mycket! Kolla egen (och andras) kod med fet last, ta dumpar och titta efter mönster. Egentligen är det inte så många olika saker som kan hända, det flesta issues faller i en av typ 5 hinkar. Sen är det bara transport till mål. Sällan det inte går att pinnpointa en issue, särskilt inte om det är .net och man har tillgång till källkod, då är det oftast bara en tidsfråga... (Ok, har ni inte källkoden, eller har sprungit på en riktigt hårig historia, fortsätt läs stycket längst ned...)
Våra riktiga hjältar sitter som coola escalation-engineers, Tess Ferrandez har en MAKALÖS!!! blogg där hon tar upp MYCKET bra debugging saker. Jag skulle börja med att styra in min rss läsare på den (http://blogs.msdn.com/tess).
Hennes kollega och cubiclemate har oxo en lysande bra blogg på http://blogs.msdn.com/johan
Jämfört med dem är jag en fet amatör! :-)
Läs oxo John Robbins BugSlayer kolumn i msdn och läs hans bok (http://www.amazon.com/Debugging-Microsoft-Applications-Pro-Developer-Paperback/dp/0735622027/ref=pd_bbs_sr_1/104-0676770-3213569?ie=UTF8&s=books&qid=1174646201&sr=8-1). Mycket bra köra igång material, hur sätter man upp en symbolserver, hur funkar Son Of Strike och annat bra...
Det är inte alltid minnes-läckage trots att detta oftast basuneras ut (en term som blivit lite misshandlad), utan hög minnesanvändning pga av något annat (taskig cachning etc, dynamiskt skapade assemblies mm).
Läs allt av Jeffrey Richter, gärna den gamla härliga Programming Windows boken oxo (http://www.amazon.com/Programming-Applications-Microsoft-Windows-General/dp/1572319968/ref=sr_11_1/104-0676770-3213569?ie=UTF8&qid=1174654025&sr=11-1). En bra förståelse av hur windows är uppbyggt gör det lättare att hitta mönster, särskilt när det är native grejjer. Typ, hur ser en stack ut med en lock, monitor, critical section, en ladida....
Om du misstänker en native-mem-leak eller tycker att det är för hårigt att ta dumpar med adplus så finns det ett bra verktyg som du kan ladda ner (http://www.microsoft.com/downloads/details.aspx?FamilyID=9BFA49BC-376B-4A54-95AA-73C9156706E7&displaylang=en). IIS Diag Toolkit erbjuder något slags GUI till adplus i DebugDiag och den klarar även av att skjuta in en dll som övervakar alla heapallokeringar vilket gör att du får en bra överblick på vad som genererar native läckor. Går utmärkt att köra på andra processer än de som har något att göra med IIS + att de genererar en sexig rapport med diagram som får managers att tro att man rockar trots att man bara tryckt på en knapp...
Andra bra bloggar;
Advanced .NET Debugging
Maoni's WebLog
Vance Morrisons log
Rico Mariani's performance tidbits
Mike Stall's .NET Debugging Blog
Patrick Dussud
Roberto's debugging blog
(Snott från Tess BlogRoll)
Och om det inte går att komma vidare, öppna upp ett case hos oss. Jag har aldrig sett så mycket kompetens på ett ställe som när man stegar in hos vår support. Det är helt sjukt... Från att vara vass är man en i mängden! Uppfriskande!!! :-D
Hoppas det hjälper dig på vägen!
/Micke