SysInternals to pakiet znakomitych narzędzi wychodzących spod ręki Marka Russinovicha oraz Bryce’a Cogswella . Choć w nazwie mają Sys – co sugerowałoby ich przeznaczenie administratorskie, to my, skromni programiści także możemy skorzystać z ich funkcjonalności i użyć ich do swoich celów. Dziś pokażę, jak 3 z nich mogą wspomóc pracę developera-poszukiwacza błędów.
Produkcja
Jak wszyscy wiemy jest to takie specyficzne środowisko, że nie zawsze mamy dostęp do swoich ulubionych narzędzi (patrz Visual Studio). Oczywiście nie jesteśmy pozbawieni metod sprawdzenia się co się stało (Debugging na produkcji – VSRD, MDbg, WinDbg). Jednakże podpięcie się debuggerem do naszej aplikacji spowoduje jej zatrzymanie, co niestety nie jest czasem możliwe (czasem nawet wadliwie działająca aplikacja jest lepsza niż nic).

Process Explorer

Czyli Menadżer zadań na sterydach :). Umożliwia przejrzenie procesów i wszystkiego co z nimi związane.
ProcessExplorer
Do czego go zatem możemy wykorzystać? Przede wszystkim w dolnym panelu (jeśli jest niewidoczny trzeba go włączyć View->Show Lower Pane) możemy zobaczyć wszystkie powiązania jakie ma nasza aplikacja. Pliki, klucze rejestru, mutex’y, wątki – etc. Takie szybkie podsumowanie tego, z czego korzysta nasza aplikacja. Prawdziwe jednak morze informacji znajduje się po wyświetleniu właściwości procesu. Naszym oczom ukażą się zakładki eksponujące informacje o procesie aż do bielizny :). Od podstawowych informacji o pliku, przez wydajność procesu (pamięć, CPU, operacje I/O) do listy wątków; a w przypadku .NETowych pokaże nam jeszcze .NETowe mierniki wydajności (jak np. kolekcje GC i inne). Lista wątków dokładnie pokaże nam co w danej chwili robi nasza aplikacja i co zajmuje jej dużo cykli procesora.
Do pobrania ze stron Technet’u – Process Explorer.

Process Monitor

To zastępnik takich narzędzi jak FileMon oraz RegMon. Łączy on w sobie funkcjonalności obu i dodaje multum dodatkowych (obserwowanie ruchu sieciowego czy wątków).
ProcMon
Do czego się przydaje? Pozwala w prosty sposób, po wcześniejszym skonfigurowaniu (bez tego przeglądanie set-tysięcy zdarzeń jest bezcelowe) zobaczyć, co dzieje się w naszej aplikacji podczas jej działania. Tj. jakie pliki są szukane, odczytywane i zapisywane przez nią. Jakie klucze rejestru są przeszukiwane i jakie dane są z nich odczytywane. Dość przydatne aby zdiagnozować powód niedziałania aplikacji.
Ostatnio miałem taką sytuację, że aplikacja na pewnej maszynie nie uruchamiała się wyrzucając tajemniczy wyjątek ‘File Not Found’ w bibliotece zewnętrznej. Brak informacji o tym, jakiego pliku brakowało nie przeszkadzał w jego odnalezieniu. Uruchomienie Process Monitora wraz z jego konfiguracją, tak aby zwracał nam tylko zdarzenia związane z naszą aplikacją oraz tylko te dotyczące plików zajęło mniej niż minutę. Po zebraniu materiału dowodowego został on pogrupowany po rezultacie a następnie wyświetlone zostały tylko te zdarzenia, które miały status ‘Name Not Found’. Bardzo szybko okazało się, że brakującym winowajcą był winusb.dll. Solved!
Do pobrania ze stron TechNet’u – Process Monitor.
Miłego używania i debuggowania!