Just do I(nformation)T(echnology) : Bug

Debugging voor dummies

mpriem — Thu, 19 Mar 2009 15:10:59 GMT

Een groot gedeelte van de supportcalls bij premier support heeft te maken met crashes, memory leaks en andere van die voor velen ongrijpbare problemen. In veel gevallen is de oorzaak echter redelijk simpel te achterhalen, en zou je een support call en veel tijd en ergernis kunnen besparen. Het probleem is dat velen niet weten dat je geen die-hard debugger hoeft te zijn om een memory dump te analyseren (ok. Ok. Eerste stap daartoe J.), of een memory leak te traceren.

Je hebt alleen de juiste tools nodig een klein duwtje in de goede richting. Die ga ik je vandaag geven J

Tools

Er zijn een aantal tools die in mijn optiek niet mogen ontbreken in de gereedschapskist van een admin. Dat zijn:

Windows debugging tools: http://www.microsoft.com/whdc/DevTools/Debugging/default.mspx
DebugDiag 1.1: http://www.microsoft.com/downloadS/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

De installatie spreekt voor zich, dus daar ga ik jullie niet mee vervelen, echter voor de debugger die we gaan gebruiken (WinDBG) is het aan te raden een symbolserver te configureren (http://www.microsoft.com/whdc/DevTools/Debugging/debugstart.mspx) . In principe is dat voor deze eerste stapjes in de wereld van debugging nog niet nodig, maar ik zou het niet laten, daar het je toch net even wat meer inzicht geeft in wat er precies gebeurd onder de motorkap. Ik prefereer de Environmental Variable, aangezien deze door veel debugtools automatisch wordt opgepakt.

Introductie

In deze post ga ik drie type scenario's behandelen. Dat zijn:

Eerste analyse van een kerneldump, naar aanleiding van een crash/BSOD (Blue-Screen-Of-Death).
Troubleshooten van usermode crashes.
Troubleshooten van memorydumps.

Voordat we daaraan beginnen zal ik toch een klein stukje theorie moeten behandelen, om een en ander duidelijk te maken.
Moderne CPU architecturen hebben verschillende modi waarin zij opereren. Deze noemen we ook wel Rings (er zijn nog tig andere benamingen). Deze modi stellen een ontwikkelaar in staat bepaalde functionaliteit van de CPU architectuur niet toe te staan voor de code die op dat moment wordt uitgevoerd. Denk hierbij aan toegang tot bepaalde CPU registers of onderdelen van het geheugen. Dit om de stabiliteit en veiligheid van het systeem te waarborgen. In Windows NT besturingssystemen (Alles behalve 3.*, 9* en ME) maken we gebruik van 2 van deze modi, namelijk de modus waarin alles is toegestaan, welke wij 'Kernelmode' noemen (Ring 0) en een modus waarin toegang tot hardwareresources beperkt worden, welke wij 'Usermode' noemen (Ring 3; in x86 en x64 architecturen zijn het er 3 (Ring 1,2,3), maar Windows gebruikt alleen de meest beperkte). De structuur van Windows zorgt ervoor dat eigenlijk alleen code die hoort bij het operating system in Kernelmode mag draaien. Er zijn wat uitzonderingen, waarvan drivers de meest belangrijke zijn.
Code wat in Kernelmode draait heeft dus onbeperkt toegang tot systeemresources, en kan dus ook geheugen structuren veranderen van andere processen, wat kan leiden tot datacorruptie, dataloss en een instabiel systeem. Windows beschermt zich hiertegen door in dergelijke gevallen op de noodknop te drukken en het systeem te stoppen of bugchecken met een BSOD. Wij noemen dit een crash, maar het is eigenlijk Windows die je redt van nog grotere problemen. Windows zal dan op basis van de instellingen wel of niet een dump maken van het kernelgeheugen. Dit heb je niet voor usermode processen.
Code wat in Usermode draait heeft dus beperkte toegang tot systeemresources. Zo heeft het alleen toegang tot geheugenbereik dat het proces toegewezen heeft gekregen en dient het toegang tot hardware aan te vragen bij het operating system. Qua performance lever je hierdoor wel wat in, maar bijkomend voordeel is dat het ene proces niet zo makkelijk een ander proces om zeep kan helpen, laat staan een BSOD kan veroorzaken, en je een verhoogde mate van veiligheid hebt, doordat geheugenstructuren van het ene proces niet uit te lezen zijn door het andere proces.

Waarom is deze informatie nu belangrijk?

Voor deze post om twee redenen:
Enerzijds is het belangrijk om te weten dat een BSOD dus in bijna alle gevallen veroorzaakt wordt door OF een bug in het operating system, OF een driver.
9 van de 10 keer zal het gaan om een driver.
Anderzijds is het belangrijk om te begrijpen dat het analyseren van een usermode crash anders is dan het analyseren van een kernelmode crash. Bij een kernmode crash heb je vaak de beschikking over een volledige dump van het geheugen. Bij usermode crashes, moet je memorydumps zelf generen en verzamelen.

Blue Screen of Death – BSOD

Wanneer een systeem geplaagd wordt door BSODs is de eerste plaats waar je gaat kijken de memorydump. Ik ben van mening dat elk systeem geconfigureerd moet zijn om een volledige dump te maken, daar in de volledige dump de meeste informatie staat. Je kan met een MiniDump soms ook wel af, maar meestal zal een support engineer vragen om de volledige dump. Ik neem aan dat je jouw systeem niet nogmaals wilt laten crashen met alle gevolgen van dien voor de data en uiteindelijk de business. Opties voor het maken van een memorydump kan je vinden op http://support.microsoft.com/kb/254649/en-us

Verder adviseer ik mijn klanten altijd, dat als er een memorydump heeft plaatsgevonden, deze veilig te stellen. Een volgende dump overschrijft deze namelijk. Meerdere dumps is handig daar de oorzaak van de crash niet altijd meteen duidelijk is. Helaas is dit vaak het geval. Het kan namelijk zijn dat de veroorzaker van de crash allang uit het geheugen is verdwenen, voordat het systeem struikelt over het probleem dat deze code veroorzaakt heeft. Door meerdere dumps te analyseren kan je soms correlaties trekken, en zo tot een conclusie komen.

Goed… We hebben een crash gehad en we hebben een memory dump. What's next??

We starten WinDBG en openen de memory dump. Deze dump is standaard te vinden op %SystemRoot%\Memory.dmp. Je kan uiteraard de memory dump naar een andere machine kopiëren en hem daar analyseren:

Nu je de memorydump geopend hebt, zal WinDBG de dump snel analyseren. Dit levert al vaak meteen waardevolle informatie op, zoals je kan zien op de analyse van 1 van mijn recente dumps:

Probably caused by : rismcx64.sys … Schijnbaar geeft WinDBG rismcx64.sys de schuld. Een korte blik in mijn drivers, gaf aan dat het om een smartcard driver ging uit 2006. Even een bezoekje aan de Windows Update en de vendor website en voila.. Nieuwe drivers. Sindsdien heb ik die crash nooit meer gehad.

Nu kan je WinDBG een verbose output laten zien van deze analyse, waar je vaak ook wel wat aan hebt. Dit doe je door !analyze –v uit te voeren. De output laat dan bijvoorbeeld ook de stacktrace zien, die je een idee kan geven, van wat het systeem op dat moment aan het doen was:

Je leest een stacktrace altijd van onder naar boven. In mijn dump was windows duidelijk bezig met het afhandelen van een IO request richting mijn smartcard device, te zien aan termen als IopXxxControlFile, NTDeviceIoControlFile en andere IO routines. Verder zie je verwijzingen naar Wdf modules wat staat voor Windows Driver Foundation. Deze informatie kan ik zien doordat ik WinDBG geconfigureerd heb om de public symbols van de Microsoft SymbolServer te halen. Zonder symbols ziet de output er anders uit.

Een hele hoop van de functienamen zijn weggevallen. Hierdoor is het lastig in 1 oogopslag te bepalen of de modules behoren tot het besturingssysteem of niet. Ik kijk altijd even naar de stacktrace. Je kan bijvoorbeeld zien of er nog andere 3rd party modules zijn die rond die tijd acties aan het uitvoeren zijn geweest. Deze kan je dan vervolgens eveneens aan een grondig onderzoek onderwerpen.

Zo zie je… In een aantal simpele stappen kan je al snel wat zaken uitzoeken en proberen voordat je een case aanmeldt om een BSOD te laten onderzoeken.

User mode crash

Voor usermode crashes heb je standaard geen memory dumps. Echter je kan een debugger attachen aan een proces en een memory dump laten generen op het moment dat deze klapt. In de debugging tools kan dat op verschillende manieren, maar ik gebruik eigenlijk altijd DebugDiag, wat een schil rondom de debuggers uit de debugging tools is.

In mijn geval crashed een application pool regelmatig. Ik start dus debugdiag en kies voor de 'Crash' optie (een Hang is niet hetzelfde als een crash):

Vervolgens kan ik twee kanten op. Ik kan kiezen voor een proces, en selecteer gewoon het juiste w3wp.exe proces, of ik kies voor Application Pool. Dit is uiteraard eenvoudiger dus doe ik dat:

Vervolgens kies ik de application pool, en krijg ik de mogelijkheid om advanced opties mee te geven, zoals op welke Exceptions debugdiag moet reageren. Ik selecteer gewoon de standaard opties, daar dat in de meeste gevallen voldoende is.

Uiteindelijk kies ik Next > Next > Activate Rule.

Als dan vervolgens het proces klapt, maakt DebugDiag een memory dump, welke geanalyseerd kan worden. Na een paar keer mijn webapplicatie te hebben geprobeerd te starten, had ik 3 memory dumps:

Ik kan dan vervolgens kiezen om de data te laten analyseren door Analyze Data te selecteren. Na een tijdje door de dumps te hebben gewroet, laat DebugDiag een rapport zien met de bevindingen. In de meeste gevallen kan je dat rapport gebruiken om verder onderzoek te plegen. In mijn geval wist ik wat het probleem was, daar ik zelf een kapotte ISAPI filter had gebakken om demo's van DebugDiag te geven. Het rapport laat daarom ook netjes zien dat mijn UpCaseStackOverflow.dll filter het probleem heeft veroorzaakt.

Memory Leaks

Memory Leaks worden vaak gezien als zeer lastige problemen om te analyseren, maar met de juiste tools valt dat best mee. Ook hier gebruik ik meestal DebugDiag voor. Je start DebugDiag en kiest voor Memory and Handle Leak. Vervolgens kies je het proces waaraan je de debugger wilt koppelen. Het valt hier op dat we nu niet de keuze hebben om een Application pool te kiezen. Als je nu meerdere application pools hebt, en deze ook nog eens onder hetzelfde application pool account draait, lijkt het lastig deze processen te onderscheiden. Gelukkig is er een redelijk makkelijke manier om erachter te komen om welke application pool het gaat. Je scrolled helemaal naar rechts in het DebugDiag window en controlleert de commandline kolom. Dit bevat de naam van de application pool:

Je dient vervolgens aan te geven wanneer er precies een Memory dump gemaakt moet worden. Dit kan na een bepaalde tijd, maar vaak is het handiger een maximum aantal MB's aan te geven. Dit doe je door te kiezen voor Configure in de Userdump generation sectie:

Ik kies hier meestal voor Virtual Bytes, omdat Private Bytes daar een subset van is. Virtual Bytes is namelijk het aantal bytes dat het proces gealloceerd heeft binnen het Virtual Address Space van het proces. Private Bytes is het geheugen dat gealloceerd is dat exclusief te benaderen is door het proces. Wanneer een proces namelijk een module laadt met shareable data (code afhankelijk dus), die al geladen is door een ander proces, wordt deze niet nogmaals in het geheugen geladen, maar gedeeld door processen. Dit geheugen wordt gemapped naar het proces. De virtual bytes geven vervolgens aan dat het proces het aantal bytes voor die module gealloceerd heeft, maar fysiek is er geen extra geheugen gebruikt. Deze shareable bytes zie je dus ook niet terug in de Private Bytes.

Om te bepalen wanneer een memory dump te maken, zal je monitoring moeten inregelen. Dit kan door System Monitor (perfmon) te gebruiken en de Private Bytes en Virtual Bytes van het systeem en processen te monitoren.

Als laatste selecteer ik weer Next > Next > Activate Rule en kan het wachten beginnen.
Zodra er weer een memorydump is gemaakt, kies je wederom voor Analyze Data en Voila… een rapport.

Net als bij de Usermode Crash, was het in mijn geval wederom een zelf geschreven ISAPI filter, met ditmaal een memory leak. Het rapport laat ook netjes zien dat er een module UpCaseLeak.dll is in mijn w3wp.exe proces die aardig wat geheugen heeft gealloceerd. In dit geval heeft DebugDiag te kort gelopen om echt een harde analyse te doen, maar je snapt waar dit heengaat.

Zo zie je… Debugging is niet alleen voor code junkies, maar iedereen kan een aantal basis stappen zetten, die in veel gevallen al tot de oorzaak van het probleem kunnen leiden!

MSExchangeIS event id 9874 (icm Forefront)

mpriem — Wed, 23 Apr 2008 17:44:00 GMT

Op verschillende plaatsen heb ik meldingen gelezen over bedrijven die last hebben van eventid 9874:
Event Type: Warning Event Source: MSExchangeIS Event Category: Virus Scanning Event ID: 9874 Date: 3/17/2008 Time: 12:23:57 PM User: N/A Computer: <servername> Description: Unexpected error 0x50a occurred in "EcProcessVirusScanQueueItem" during virus scanning. Mailbox Database: /o=<orgname>/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=<servername>/cn=Microsoft Private MDB Folder ID: 1-24 Message ID: 1-D616AA3D

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Dit event heeft te maken met dat Forefront bepaalde instellingen in het register niet goed kan verwerken. In mijn geval had het te maken met Background scanning opties die niet aanwezig waren in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\VirusScan].

Dit is de juiste inhoud van de key voor een server met alleen de mailboxrole (De ontbrekende DWORDS zijn vet gedrukt):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\VirusScan]
"Library"="C:\\Program Files (x86)\\Microsoft Forefront Security\\Exchange Server\\FSEVsapiEx.dll"
"BackgroundScanning"=dword:00000000
"ProactiveScanning"=dword:00000000
"ScanRTF"=dword:00000001
"ScanTimeout"=dword:00000258
"EnableScanDeletion"=dword:00000001
"OnAccessScanningRollingLowerAgeLimit"=dword:00360d80
"ReloadNow"=dword:00000000
"Enabled"=dword:00000001
"OnAccessThresholdVersion"=dword:00000001
"BackgroundScanningIgnoreStamp"=dword:00000001
"BackgroundScanningOnlyUnscanned"=dword:00000001
"BackgroundScanningAttachmentMessagesOnly"=dword:00000001

Dit kwam omdat de Background scanning job een keer gedraaid moet hebben om deze key op de juiste manier te vullen. Dit doe je door in Forefront het schedule voor de background scanning job aan te passen dat de job in ieder geval 1 keer draait.

Microsofts best practice is om deze job wekelijks te draaien en dan alleen unscanned berichten te scannen, ontvangen in de laatste week, met attachment.

Meeting forward notification crashed Outlook

mpriem — Mon, 11 Feb 2008 18:43:00 GMT

In Exchange 2007 heb je een nieuwe functie die ervoor zorgt dat de organisator van een meeting een forward notificatie krijgt als zijn meeting geforward wordt naar een andere mailbox.

Outlook 2003's "New Mail Desktop Alert" kan daar echter niet goed mee omgaan en crashed Outlook 2003 als deze niet op SP3 zit.

Oplossingen/Workarrounds zijn dus:

Disable de "New Mail Desktop Alert" via Options > Preferences > E-Mail Options > Advanced E-Mail Options> uncheck "Display a New Mail Desktop Alert".
Uitrollen SP3 voor Outlook 2003
AV of Antispam oplossing dusdanig configureren dat de Meeting forwards niet aankomen

Exchange 2007 SP1 veroorzaakt problemen met Calendar items icm Blackberry

mpriem — Fri, 04 Jan 2008 18:42:00 GMT

Blackberry Enterprise Server 4.1 MR4 geeft problemen met calendar items in combinatie met Exchange 2007 SP1.
Wanneer een meeting request ontvangen wordt op de Blackberry, flagt het device deze als 'Tentatively Accepted'.

In Outlook zie je het volgende op het meeting request bij de uitgenodigde met een Blackberry:

Degene die de meeting georganiseerd heeft, heeft echter geen response gekregen:

Dit probleem treedt op ongeacht welke handheld je hebt. Het probleem is bekend bij RIM, echter het response is minder leuk:

"Thank you for contacting BlackBerry Customer Support.

The issue you have found has been identified by the BlackBerry Development Team and has been flagged to be addressed. The SDR relating to this is SDR144817 and all I can advise is you check the next release of the BlackBerry Enterprise Software if this has been fixed and included it will be in the release notes"

Nog een reden waarom Public folders mogen verdwijnen.....

mpriem — Fri, 07 Dec 2007 18:27:00 GMT

Naast het feit dat ik een mailsysteem geen plek vind om informatie met elkaar te delen, ben ik deze week achter nog een reden gekomen waarom public folders uit Exchange 2007 moeten verdwijnen. Dit heeft alles te maken met een probleem waar ik een maand mee bezig ben geweest...

Vorige maand is de klant waar ik momenteel voor werk een Exchange 2007 pilot gestart in een redelijk grote bestaande Exchange 2003 organisatie. Deze omgeving telt 100+ servers verspreid over 4 continenten. Daarbinnen hebben ze 52 Public Folder stores.

De initiele pilot groep telde +- 30 gebruikers, welke in UAT uitgebreid zou gaan worden naar +- 250 gebruikers. Vanaf het begin af aan kreeg ik klachten dat geheel willekeurig een Outlook client ineens bleef hangen voor 1 a 2 minuten, waarbij "retrieving data" popups verschenen, welke verwezen naar de 2007 public folder server die opgetuigd was voor de pilot users. Na verschillende perfmon sessies te hebben gedraaid op deze server, kon ik geen performance issues vinden. De hardware functioneerde prima, en ook de lokale GC's lieten geen problemen zien. Wel zagen we om het half uur hoge "RPC average latency" pieken. Na ook met network monitor aan de slag te zijn gegaan konden we zien dat de server elk half uur een waslijst aan Exchange servers verspreid over het hele forest aan het benaderen waren. We konden alleen zien dat het NetLogon verkeer was, aangezien de content encrypted is.

Microsoft werd erbij gehaald, maar na een week ploeteren hadden we nog geen inzicht in wat het probleem nou precies was. We hadden in de tussentijd al van alles gedaan. IsInteg gedraaid, andere public folder stores geprobeert. Aangezien de problemen zo willekeurig optraden konden we niet goed zien wat er nu precies gaande was. Het leek erop dat het probleem vaak optrad bij het opstarten van Outlook. Echter waren er ook berichten dat het ook gebeurde als iemand andere zaken aan het doen was of zelfs helemaal niets aan het doen was. In een poging het probleem in de kraag te vatten had ik Netmon op mijn werkstation weten te krijgen (is gesloten omgeving dus was een hele klus om toestemming te krijgen). Door via script Outlook om de 7 seconden te openen en te sluiten, hoopte ik te kunnen tracen wat Outlook nou precies vraagt, waar Exchange nu zo'n moeite mee heeft. na 3 uur had ik beet. Na de capture opgestuurt te hebben naar Microsoft (zij kunnen namelijk delen van RPC pakketjes decrypten), bleek dat het om een request te gaan waarbij Outlook vroeg op content van de "Outlook Security Forms". Om er zeker van te zijn moesten we proberen nog een packet te capturen, maar tegelijkertijd ook een perfmon en netmon sessie op de server te starten.

Dit bleek lastig aangezien we al moeite hadden het te triggeren met script. Op mijn werkstation was het al meer dan een week niet "zomaar" voorgekomen. Na intern overleg had ik toestemming op nog een aantal werkstations netmon te installeren. Echter bleek dit niet nodig te zijn, want na ik wat beter naar de netmon capture van de server te kijken en naar de perfmon sessie, kon ik een patroon vinden waarbij er telkens om het half uur een RPC request gedaan werd, waarna Exchange al die PF servers afging. Nadat dat klaar was, kwam er een RPC response, en precies op dat moment schoot de RPC average latency omhoog. Microsoft vroeg mij verschillende malen memorydumps te maken van store.exe. Tijdens de rpc peak, vlak voor de rpc peak etc etc. In totaal hebben we 15 GB aan dumps op moeten sturen. In de tussentijd was er een CPR engineer onsite geweest omdat MS zelf ook niet wist wat er nu precies gaande was. Veel meer dan meekijken kon hij niet. Kreeg meer de indruk dat hij kwam kijken of we de boel niet voor de gek aan het houden waren.
Enfin, Na een paar dagen was Microsoft klaar met het analyseren van de memory dumps en wat bleek. Het probleem werd veroorzaakt doordat Outlook de Public Folder hierarchy wilde laten reloaden. Dit kwam doordat er public folder stores in de hierarchy zaten die niet meer bestonden. Dit kan komen doordat public folder stores voor Exchange 2003 sp2 gewoon verwijdert konden worden, zonder de replicas te verplaatsen naar andere servers. Nu had ik in die omgeving al een keer een schoningsactie gehouden waarbij System folders van oude stores verwijdert waren en de replicalijst aardig schoon was (replstate test van ISINTEG schoont deze op). Echter het blijkt dat de replicalijst ook nog op andere plaatsen in de PF store opgeslagen wordt. Deze "orphaned" entries op die plek kunnen dus niet verwijdert worden en zorgen ervoor dat ze blijven voorkomen in de hierarchie. Outlook ziet de guids van deze nietbestaande PF stores en zal elke keer wanneer het de hierachie opvraagt vragen om een reload. Nu doet Exchange dit standaard 1 keer per uur, maar op aanvraag doet Exchange dat dus sneller, als er maar minimaal een half uur tussen zit.... Laat dat nu net de interval zijn dat we die high latency pieken zien.

Wat blijkt nu? In Exchange 2003 hadden we dat probleem dus ook, maar hadden we geen Outlook clients die hingen. Dat komt omdat de reload van Exchange 2003 veel sneller ging. In Exchange 2003 gebruiken we routinggroup connectoren met costs. Door een paar snelle AD queries kan Exchange dus heel snel de hierarchie opbouwen.
In Exchange 2007 gebruiken we echter AD sites met costs. Echter op een serverobject in AD staat niet in welke AD-site deze zit. Exchange moet dat dus zien te bepalen. En waar hebben de programmeurs voor gekozen??? ...Precies... Een sessie opzetten met de server om zo de site te achterhalen. Vandaar dat we de Netlogons zagen. En servers in Azie en Australie reageren nu eenmaal niet zo snel als ze achter high latency lijntjes zitten. Dus om het half uur wachtte een client totdat Exchange sessies had opgezet naar 52 PF server in de organisatie.

Hoe nu verder? Nou... Niet met Exchange 2007 public folders dus voorlopig. Als het aantal is teruggebracht van 53 naar 8, dan kunnen we erover denken, maar nu niet.
Er is wel de mogelijkheid om het interval van reloaden aan te passen. Dit doe je door een DWORD aan te maken in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MsExchangeIS\\Public-(guid)

Dit DWORD moet heten "Replication Reload TLH Min" en de waarde is het aantal seconden die minimaal moeten zijn verstreken sinds de laatste reload. De maximale waarde is 43200 decimaal (12 uur). Zo kan je ervoor zorgen dat het probleem slechts 1 keer per 12 uur optreed. De enige echte structurele oplossing is om de hele PF tree opnieuw op te bouwen. Dat is echt heel erg lastig in grote omgevingen.

Omdat de programmeurs niet echt handig zijn omgesprongen met het reloaden van de hierarchie in Exchange 2007 is dit probleem nog in onderzoek bij de productgroep. Hopelijk wordt er een aanpassing gemaakt. Misschien wordt dit zelfs als bug aangeduid. Hoe het ook wil, op dit moment zijn public folders in grote omgevingen dus RUK...

Van mij mogen ze verdwijnen.