Das Debugging eines Workflows ist nicht immer ganz einfach. Bei einem SharePoint Workflow hat man verschiedene Bedingungen die es einem erschweren. So wird zum Beispiel bei einem CreateTask Activity der Task nicht gleich erstellt sondern asynchron erst zu einer späteren Zeit. Falls nun das Erstellen dieses Tasks fehl schlägt merkt man dies im eigenen Code vielleicht gar nicht. Wenn man nun mit dem Visual Studio am debuggen ist und herausfinden will wieso der Task nicht erstellt wird bekommt man keine Exception. Der eigene Code wird durchlaufen. Bei einem State Machine Workflow wird je nach Implementation sogar der ganze State durchlaufen. Erst bei der nächsten Dehydration wird der Task erstellt.
Doch in diesem Beispiel gehen wir davon aus, dass der Task eben nicht erstellt wird. Es kann sich auch um ein UpdateTask Activity handeln oder schlicht ein Activity welches seine Arbeit asynchron erledigt.
Auf dieses Beispiel möchte ich hier nicht weiter eingehen. Es soll auch nur dazu dienen ein Beispiel aufzuzeigen wo der Code nicht vorhanden ist und man auch keine Exception bekommt. Und man somit nicht so einfach herausfinden kann was man genau für Problem vor sich hat.
Bei einer Solchen Situation müsste man das Problem aus ein wenig Distanz ansehen. Dabei kann man mit verschiedenen Ansätzen vorgehen. Einer ist das von Ingo Rammer an den TechDays von Microsoft vorgestellte Tool WinDbg. Mit WinDbg kann man einen Dump des Memory erstellen. In dem Dump kann man nach der Exception suchen. Dabei muss man sich überlegen wie man den Dump erstellen möchte denn schliesslich soll die Exception auch darin enthalten sein. Man hat auch die Möglichkeit an einer globalen Stelle im eigenen Code einen Dump zu erstellen. Dabei sollte man aber gut Überlegen wie man das macht und mit welchen Parametern man den Dump erstellt. Je nachdem wie gut die eigene Applikation ist. Hat man schnell ein paar Dumps zusammen. ;-)
Die Arbeit mit Dumps kann eine sehr zeitintensive Angelegenheit sein. Bei der Entwicklung von WinForm Anwendungen kann man eine Anwendung direkt mit dem WinDbg starten somit kann man bei einer Exception anhalten und direkt den Dump nach dem Problem durchsuchen. Bei einem Server den ganzen w3wp Prozess über WinDbg laufen zu lassen ist aber kaum möglich.
Aus den gleichen Gründen wie debuggen mit Visual Studio auf dem Server nicht erwünscht ist, ist auch eine solche Aktion nicht erwünscht: Wenn irgendwo ein Benutzer vor dem Bildschirm sitzt und auf seinen Browser wartet. Ist ein step-by-step Debugging nicht nett. :-)
Da hilft einem Adplus weiter. Adplus wird ebenfalls mit den Debugingtools for Windows mitinstalliert. Eine Anleitung wie man einen Dump bei einer Exception erstellt findet man hier:
Wenn man einen dieser Wege wählt hat man zwar einen Dump doch die Arbeit ist noch nicht erledigt. Danach muss man noch den Fehler finden.
Habe eine nützliche Seite zu diesem Thema gefunden: WinDbg / SOS Cheat Sheet leider ist sie momentan nur im Google Cache zu finden.
Falls die Seiten ganz verschwinden sollten hier eine kleines Beispiel:
- Crashdump öffnen über das Menu
Falls WinDbg folgende Meldung bringt "This dump file has an exception of interest stored in it" hat man schon mal was im Dump - .loadby sos mscorwks
Laden des SoS für Framework 2.0 - !threads
Anzeige der "managed" Threads - ~0s
Selektion des Threads 0
(Nur ein Beispiel. Bei Punkt 3 sollte der Thread ersichtlich sein.) - !PrintException