Używanie IntelliTrace poza Visual Studio 2010!

Home

W oficjalnej dokumentacji IntelliTrace można przeczytać, że narzędzie to jest dostępne tylko i wyłącznie z poziomu środowiska Visual Studio 2010. To bardzo źle ponieważ z góry przekreśla użycie IntelliTrace do diagnozowania błędów u klienta. Wyobraźmy sobie, że dostajemy zgłoszenie trudnego do powtórzenia błędu. Czy nie byłoby wspaniale uruchomić aplikację w środowisku produkcyjnym, pod kontrolą IntelliTrace i w razie wystąpienia błędu poprosić klienta o przekazanie nam plików z logami (*.iTrace). Nie wszystko jest jednak stracone. Pomimo, że nie jest to oficjalnie wspierane można uruchomić IntelliTrace z poza Visual Studio 2010!

Na początek należy odpowiedzieć na pytanie czym jest IntelliTrace: wątkiem działającym w ramach procesu Visual Studio 2010, niezależnym procesem, a może jeszcze czymś innym? Odpowiedź na to pytanie można uzyskać przy pomocy programu Process Explorer. Na poniższym obrazku widać fragment drzewa procesów dla węzła devenv.exe (czyli dla Visual Studio).



Pod nim znajdziemy węzeł odpowiadający debug'owanemu programowi oraz węzeł IntelliTrace, a w jego właściwościach ścieżkę z jakiej jest uruchamiany (VS_2010_INSTALL_DIR to katalog instalacyjny środowiska) np.:

VS_2010_INSTALL_DIR\Team Tools\TraceDebugger Tools\IntelliTrace.EXE

Reasumując IntelliTrace to niezależny proces, który komunikuje się z Visual Studio przy użyciu jakiegoś mechanizmu IPC (ang. Inter-process communication ). Jeśli spróbujemy go uruchomić z linii poleceń na ekran zostanie wypisana lista dostępnych komend. Z kilku dostępnych interesująca jest komenda launch, która zgodnie z podanym opisem uruchamia podaną aplikację i rozpoczyna jej monitorowanie. Po wpisaniu w linię poleceń: IntelliTrace help launch uzyskamy bardziej szczegółowe informacje na jej temat.

Z dostępnych parametrów najważniejsze to /logfile (w skrócie /f) przy pomocy, którego wskazujemy docelowy plik z logiem oraz /collectionplan (w skrócie /cp) przy pomocy, którego wskazujemy plik z planem działania, konfiguracją IntelliTrace. Skąd go wziąć? Domyślny plik używany przez Visual Studio 2010, a który jest dokumentem XML, znajdziemy w lokalizacji:

VS_2010_INSTALL_DIR\Team Tools\TraceDebugger Tools\en\CollectionPlan.xml

Mając już wszystkie elementy układanki, spróbujmy uruchomić jakiś program pod kontrolą IntelliTrace ale bez pomocy Visual Studio. Poniżej pokazano takie przykładowe wywołanie. W miejsce LOG_PATH należy wstawić ścieżkę do wyjściowego pliku z logiem (najlepiej nadać mu rozszerzenie iTrace), w miejsce COLLECTION_PLAN_PATH ścieżkę do pliku CollectionPlan.xml (może nazywać się inaczej i mieć inne rozszerzenie). PROGRAM_PATH to oczywiście ścieżka do programu jaki chcemy monitorować.

VS_2010_INSTALL_DIR\Team Tools\TraceDebugger Tools\IntelliTrace.EXE launch /f:LOG_PATH /cp:COLLECTION_PLAN_PATH PROGRAM_PATH

Po wykonaniu tego polecenia we wskazanym przez nas katalogu pojawi się plik z logiem. Jeśli będzie miał rozszerzenie iTrace to po dwukliku uruchomi się Visual Studio 2010. W tym momencie czeka nas jednak niemiła niespodzianka ponieważ okaże się, że plik z logiem nie zawiera żadnych informacji tak jakby program nie był monitorowany.



Na brakujący element układanki naprowadzi nas ponownie Process Explorer, który umożliwia podejrzenie parametrów wywołania programu. Interesuje nas oczywiście proces IntelliTrace. Jeśli odczytamy jego parametry wywołania to dowiemy się, że został uruchomiony z komendą run, a nie launch. Różnica polega na tym, że run w przeciwieństwie do launch uruchamia tylko proces monitorujący i nie wskazuje konkretnej aplikacji do monitorowania. To jaka aplikacja będzie monitorowana zależy od Visual Studio 2010. Kolejna, ważna dla nas różnica to wartość parametru /cp, który nie wskazuje na domyślny plan wykonania ale na jakiś "dziwny" plik np.:

C:\Users\user\AppData\Local\Microsoft\VisualStudio\10.0\TraceDebugger\Settings\frueouq2.vfs

Jest to plik tymczasowy, a jego nazwa generowana jest w sposób losowy. Jeśli spróbujemy go otworzyć to okaże się, że bardzo przypomina domyślny plik CollectionPlan.xml. Dokładniej mówiąc schemat XML jest taki sam, inne są natomiast wartości atrybutów, liczba węzłów itd. czyżby brakujący element układanki? Tworzymy, więc kopię tego pliku, wskazujemy go w parametrze \cp i ponownie wydajemy wcześniej pokazane polecenie. Tym razem po otworzeniu wynikowego pliku z logiem zobaczymy listę monitorowanych wątków, drzewo wywołań itd.



Pełny sukces? Niestety nie do końca. Po bliższym przyjrzeniu się zauważymy, że mamy dostęp tylko do drzewa wywołań, a brakuje informacji o zdarzeniach diagnostycznych (ważne punkty w historii wykonania programu np.: wykonanie zapytania do bazy danych). Tego ograniczenia nie udało mi się jeszcze ominąć. Przypuszczam, że przy uruchamianiu IntelliTrace przez Visual Studio 2010 do programu przekazywane są jakieś dodatkowe opcje. Być może do rejestrowania zdarzeń potrzebne jest Visual Studio, a logger IntelliTrace nie potrafi tego robić?

Najważniejsze jest jednak to, że już teraz IntelliTrace można uruchomić niezależnie od środowiska programistycznego, chociaż z pewnymi ograniczeniami. Biorę to za dobrą monetę i mam nadzieję, że pełne wsparcie dla uruchamiania IntelliTrace z poza Visual Studio jest w planach Microsoft'u i pojawi się, jeśli nie z którymś service pack'iem to w kolejnej edycji Visual Studio.

Artukuł opublikowałem również w serwisie software.com.pl.

Android 2.1

Home

Pierwszy post po długiej przerwie spowodowanej urlopem :) będzie trochę z innej beczki niż zwykle, a będzie dotyczył aktualizacji systemu Android do wersji 2.1 na telefonie Samsung Galaxy GT-I5700. Postanowiłem o tym napisać ponieważ spędziłem nad tym trochę czasu, na różnych forach można znaleźć sporo pytań o to, a okazało się, że sprawa jest dość prosta. Ja napotkałem dwa główne problemy:

• Problem z wykryciem telefonu, po podłączeniu go do komputera przez kabel USB, przez oprogramowanie Samsung PC Studio.
• Zawieszenie się telefonu w czasie aktualizacji.

Pierwszy problem rozwiązuje się właściwie sam. Jakiś czas temu pojawiła się aktualizacja aplikacji Samsung PC Studio. Po uruchomieniu programu otrzymamy komunikat z informacją o możliwość pobrania i zainstalowania uaktualnienia. Po zakończeniu procesu problem z wykrywaniem telefonu powinien zniknąć (u mnie ustąpił). Jeśli PC Studio cały czas uparcie nie widzi telefonu należy sprawdzić czy telefon ma włączone Debugowanie USB. Opcję tą znajdziemy tutaj: Ustawienia -> Aplikacje -> Programowanie -> Debugowanie USB.

Drugi problem polegał na tym, że po rozpoczęciu aktualizacji telefon w pewnym momencie wyłączył się, a przy ponownym uruchomieniu zawiesił na czarnym ekranie z napisem Samsung. Po przeczekaniu kilkunastu minut straciłem cierpliwość i odłączyłem (wbrew zaleceniom) telefon od komputera oraz go wyłączyłem wyjmując baterie (również niezalecane). Kolejne uruchomieniu telefonu odbyło się szczęśliwie bez kłopotów ale system oczywiście nie został uaktualniony.

Po chwili przypomniałem sobie, że używam dobrze znanej wielu osobom aplikacji APNdroid dzięki, której telefon nie połączy sie z netem poprzez sieci 2G/3G/EDGE bez naszej wiedzy (tak na marginesie polecam). Standardowo dostęp do sieci mam wyłączony i miałem niejasne przeczucie, że tutaj tkwi rozwiązanie problemu. Moje przeczucie okazało się trafne. Po włączeniu dostępu do sieci 2G/3G/EDGE i ponownym rozpoczęciu procesu aktualizacji wszystko się udało.

Na zakończenie kilka uwag. Przed rozpoczęciem aktualizacji warto wykonać kopię zapasową danych na telefonie. Pytanie o to czy chcemy wykonać taką kopię pojawi się w kreatorze aktualizacji. Po drugie zwracam uwagę, że odłączania telefonu od komputera w czasie aktualizacji jest niebezpieczne i może doprowadzić do utraty danych lub uszkodzenia telefonu. Ja byłem zmuszony to zrobić i się udało ale w żadnym stopniu nie zalecam powielania tej procedury. Najlepiej zrobić wszystko od początku do końca prawidłowo :) Na koniec przypominam, że po wykonaniu aktualizacji nie będzie już można korzystać z PC Studio do komunikacji z telefonem. Zamiast tej aplikacji należy pobrać nową o nazwie KIES