Uruchamianie aplikacji na 64 bitach

Home

Pierwszy wpis w nowym roku 2010 będzie dotyczył zagadnienia uruchamiania aplikacji .Net'owych na maszynach 64 bitowy. W większości przypadków nie ma z tym żadnego problemu. W końcu IL jest przenośny. Problemy zaczynają się kiedy chcemy wykorzystać w swojej aplikacji biblioteki 32 bitowe. Niestety ale nie jest możliwe aby proces 64 bitowy używał bibliotek 32 bitowych i na odwrót. Przeważnie nie mamy również możliwości przekompilowania biblioteki, z której korzystamy. Ja spotkałem się z tym problem uruchamiając aplikację, która do połączenia z bazą danych korzystała ze sterownika ODBC. W czasie jej uruchomienia pojawiał się komunikat:

Dostawca 'Ifxoledbc.2' nie jest zarejestrowany na lokalnym komputerze.

Komunikat mnie zdziwił ponieważ byłem pewny, że dostawca jest zarejestrowany. Przypomniałem sobie jednak, że jest to sterownik 32 bitowy. Jak sobie poradziłem?

Ogólnie są dwa rozwiązania tego problemu. Po pierwsze można w właściwościach projektu ustawić opcję Target CPU na X86. Domyślna wartość to Any CPU. Jeśli z jakichś powodów nie możemy zrekompilować aplikacji możemy skorzystać z programu corflags. Jest on instalowany razem z Visual Studio i pozwala przełączyć aplikację w 32 bitowy tryb pracy np.:

corflags /32bit+ aplikacja

W razie potrzeby ponownego przełączenia na 64 bitowy tryb pracy używamy następującej składni:

corflags /32bit- aplikacja

BadImageFormatException i TFS

Home

Przed paroma dniami zainstalowałem na swoim komputerze najnowszą wersję serwera TFS czyli Microsoft Visual Studio Team Foundation Server 2010 Beta 2. Instalacja przebiegła szybko i bezproblemowo z dokładnością do tego, że wcześniej musiałem jeszcze zainstalować SQL Server 2008 oraz, co trochę dziwne dla mnie, najnowszy Service Pack dla systemu Windows Vista.

Kiedy instalacja dobiegła końca uruchomiłem konsolę Team Foundation Administration Console, dalej użyłem kreatora konfiguracji i pomyślałem, że będę mógł się cieszyć nową zabawką. Niestety próba podłączenia się do serwera, czy to z poziomu VS 2010 czy to z poziomu programu Microsoft Test and Lab Manager, kończyła się błędem Unable to connect to Team Foundation Server.

Próbując rozwiązać problem dotarłem do systemowego logu zdarzeń. Tam znalazłem kilka podejrzanie wyglądających zdarzeń, których źródło nazywało się TFS Services. Aby upewnić się co do ich pochodzenia zatrzymałem pulę aplikacyjną Microsoft Team Foundation Server Application Pool, do której należą usługi TFS. Odczekałem chwilę i ponownie ją uruchomiłem. Zaglądam ponownie do logu zdarzeń i znajduję serię 3 komunikatów, których czas wystąpienia zgadzał się z czasem uruchomienia puli aplikacyjnej. Dwa pierwsze komunikaty miały źródło o nazwie TFS Services, a trzeci ASP.NET 4.0.21006.0. W trzecim komunikacie znalazłem interesującą informację o wystąpieniu nieobsłużonego wyjątku BadImageFormatException.

Jeszcze chwila szukania i znajduję rozwiązanie. Okazało się, że błąd był spowodowany nieprawidłową konfiguracja wspomnianej puli aplikacyjnej Microsoft Team Foundation Server Application Pool. Miała ona włączoną opcję Włącz aplikacje 32 bitowe podczas gdy ja korzystam z wersji 64 bitowej. Po wyłączeniu tej flagi problem ustąpił i wszystko zaczęło działać.

Życzenie świąteczne

Home

Wszystkim czytelnikom i czytelniczkom składam życzenia wesołych i radosnych Świąt Bożego Narodzenia.

Serdecznie pozdrawiam
Michał Komorowski

"Dzikie żądze"

Home

W pracy komputer, na studiach doktoranckich komputer... Nie ulega wątpliwości, że dużą część dnia spędzam wpatrzony w monitor. Dlatego tak bardzo lubię wyjść z żoną na miasto, a jedną z naszych ulubionych rozrywek jest dobra komedia w teatrze.

Przedwczoraj odwiedziliśmy ponownie teatr "Bajka" na deskach, którego można teraz oglądać brytyjską sztukę "Dzikie żądze". Opowiada ona o małżeństwie Państwa Griffin. On bogaty przemysłowiec, ona lekko znudzona. Aby ratować małżeństwo postanawiają na nowo rozbudzić w sobie żądzę... Więcej z fabuły nie zdradzę, dodam tylko, że jest nieprzewidywalna, pełna zwrotów akcji i po prostu przezabawna. Przez większość przedstawienia nie robiłem nic innego tylko się śmiałem. W pewnym momencie nawet aktorzy nie mogli się powstrzymać od śmiechu. Byłbym jednak niesprawiedliwy gdybym nie powiedział, że bardzo szybko się powstrzymali.

Zaskakujące było też zakończenie wieczoru. Jeden z aktorów zaprosił na scenę młodą parę, która wygrała bilety w konkursie radiowym żeby zrobić sobie z nimi zdjęcie. Jak się okazało był to tylko "niecny" wybieg. Gdzieś znalazły się kwiaty i za chwilę chłopak na kolanach prosił swoją wybrankę o rękę :) Brawo za odwagę!

W teatrze "Bajka" po raz kolejny spędziłem wspaniały wieczór i z czystym sumieniem mogę go polecić każdemu. Teatr naprawdę nie gryzie.

Ciekawe zgłoszenie błędu

Home

Jest to druga, poprawiona wersja tego postu. Za wcześniejsze pomyłki przepraszam.

W poście tym chciałbym opisać interesujący błąd. Wszystko zaczęło się od zgłoszenia od klienta dotyczącego problemów z wydrukami. Nie wchodząc w szczegóły okazało się, że cały problem sprowadza się do utworzenia dostatecznie dużej bitmapy. Co jednak ciekawe analiza pokazała, że system dysponuje znaczną ilością wolnej pamięci (ok 1.5 GB) podczas gdy do utworzenia bitmapy potrzebne było "raptem" kilkaset megabajtów. Tutaj dodam, że mówimy o systemie 32 bitowym.

Z pomocą przyszedł tutaj program vnmap, który służy do analizy pamięci wirtualnej i fizycznej procesu. Pokazał on, że proces rzeczywiście dysponuje znaczną ilością pamięci ale największy ciągły jej obszar to tylko 200 MB. Do zaalokowania bitmapy potrzeba natomiast właśnie ciągłego obszaru pamięci. Nie dotyczy to zresztą tylko bitmap, podobny problem możemy wystąpić przy ładowaniu bibliotek dll.

Taką sytuację nazywamy defragmentacją pamięci. Co było jej przyczyną? Zgodnie z tym co pokazał wspomniany program vnamp pamięć w dużym stopniu była poszatkowana przez biblioteki dynamiczne. Nie bez znaczenia jest tutaj fakt, że rozpatrywany przypadek dotyczył dość dużego systemu zbudowanego z wielu modułów.

Problem próbowałem zaleczyć przy użyciu narzędzia rebase.exe, które służy do ustawienia preferowanego adresu pod jaki ma zostać załadowana dll'ka. Testy niestety pokazały, że to nic nie daje.

Pytanie co jest przyczyną takiego położenia bibliotek w pamięci? Tutaj nie pozostaje mi nic innego jak rozłożyć ręce. Wcześniej byłem przekonany, że jest to związane z mechanizmem bezpieczeństwa, który losowo rozrzuca biblioteki po pamięci. Zwrócono mi jednak uwagę, że taki mechanizm (ASLR) pojawił się dopiero w Windows Vista. Sprawa jest więc otwarta. Jakieś pomysły?

Jak sobie z tym poradzić? Generalnie jednoznacznej odpowiedzi nie ma, ja znam trzy podejścia. Po pierwsze przejście na system 64 bitowy rozwiąże problem ale nie jest to zawsze możliwe. Po drugie można próbować wyeliminować konieczność alokacji tak dużej bitmapy ale może to być bardzo trudne. Można też użyć przełącznika /3GB, który pozwala procesom użytkownika użyć 3 GB pamięci wirtualnej zamiast domyślnych 2 GB ale nie jest to zalecane rozwiązanie.

Na zakończenie chciałbym podziękować koledze Damianowi z pracy, który analizował zgłoszenie klienta i podsunął mi pomysł na ten post.