Wśród głównych wydarzeń corocznej konferencji TechEd poczesne miejsce zajmują prezentacje nowych technologii - inżynierowie i partnerzy Microsoftu starają się pokazać uczestnikom, metodą krok po kroku, jak ich używać, aby ich wdrażanie było łatwiejsze.

W ostatnich kilku latach jedną z najpopularniejszych sesji tego typu jest "Cases of the Unexplained", prowadzona przez Russinovich’a, w której pokazuje on jak można wyśledzić trudne do zdiagnozowania błędy w środowisku Windows.

Zobacz również:

• Nearby Sharing od Google - wygodny sposób na przesyłanie plików

W tym roku ekspert zademonstrował sposoby debugowania kilku skomplikowanych problemów, z użyciem kilku bezpłatnych narzędzi - w tym także opracowanych przez niego samego, takich jak Process Explorer czy Process Monitor. Wiele z zaprezentowanych na konferencji przykładów można znaleźć na blogu Russinovicha, gdzie gromadzi on historie "ciężkich przypadków" przekazywane przez użytkowników.

W problemach zaprezentowanych przez Russinovicha, podstawowe przyczyny niewłaściwego zachowywania się systemu nie były łatwe do szybkiego namierzenia np. przez analizę logów. Awariom programów zwykle towarzyszą dość skąpe informacje o ich przyczynie. Jednak według Russinovicha, mimo ubogiej informacji na temat "co poszło nie tak", korzystając z odpowiednich narzędzi, możemy dokładnie prześledzić objawy i ustalić przyczynę problemu.

Jeden z przykładów Russinovich dostał od administratora z pewnej korporacji. Użytkownicy narzekali na wolne otwieranie się niektórych stron intranetu. Aby zdiagnozować problem, administrator uruchomił na serwerze Process Explorer - narzędzie prezentujące wszystkie procesy oraz ilość pamięci i cykli CPU zajmowanych przez każdy wątek procesu. Jeden z wątków zajmował ponad jedną czwartą zasobów serwera. Przeszukując internet nasz administrator odkrył, że powiązany z nim proces należy do sterownika zarządzania Windows, który, z kolei, komunikuje się ze sterownikiem (producenta) dla chassis. Wiedząc już, gdzie szukać, administrator sprawdzil czy serwer blade jest właściwie wsunięty do kasety. Prawidlowe umieszczenie go okazało się rozwiązaniem problemu.

Kolejny przypadek nie był związany z niewłaściwym działaniem sprzętu czy oprogramowania, a raczej z działaniami użytkowników. Problem ten był związany z serwerem Microsoft Exchange, którego użytkownicy skarżyli się, że na opóźnione od czasu do czasu odpowiedzi serwera (do 30 sekund). Dla wyjaśnienia problemu, inżynier Microsoft poprosił administratora o logi wydajności serwera wykonanego przez Performance Monitor, który pokazywał okresowe piki w użytkowaniu CPU. Wykorzystując ProcDump, specjalista Microsoftu utworzył skrypt, który miał przechwytywać wszystkie informacje o procesie, jeśli wykorzystanie procesora przekraczało określony próg.

Przeglądając rezultaty tego śledzenia stwierdził, że funkcja przeszukiwania Exchange zajmuje dużo cykli procesora. Owa "ociężałość" Exchange spowodowana była faktem, iż pewna liczba użytkowników miała mocno przeładowane skrzynki pocztowe i kiedy wykonywano ich przeszukiwanie, obciążenie serwera znacznie wzrastalo. Administrator zalecił użytkownikom uporządkowanie skrzynek, co znacznie poprawiło wydajność serwera.