Analizuję plik .dmp, który został utworzony i mam stos wywołań, który daje mi dużo informacji. Chciałbym jednak dwukrotnie kliknąć stos wywołań i doprowadzić go do kodu źródłowego.Jak określić katalog kodu źródłowego w VS podczas przeglądania stosu wywołań zrzutu pamięci?
Mogę kliknąć prawym przyciskiem na stos połączeń i wybrać ustawienia symboli .. gdzie mogę umieścić lokalizację na WPB. Ale nie ma opcji dla katalogu kodu źródłowego.
Katalog kodu źródłowego jest niestety zakodowany na stałe w pdb, ale jeśli wiesz, że foldery są wymagane, możesz użyć okna z symbolami dowiązań symbolicznych, skrzyżowań.
mogę użyć narzędzia Junction Link Magic
Po załadowaniu WPB, ręcznie przejdź do pliku źródłowego, który pasuje do aktualnej lokalizacji wykonania. PDB zawiera ścieżkę i nazwę pliku źródłowego, który zbudował powiązany z nim plik binarny, i podejrzewam, że debugger jest wystarczająco inteligentny, aby podnieść stan, gdy zauważy, że nazwa pliku jest wyświetlana, a nazwa pliku powiązana z bieżącą lokalizacją binarną jest zgodna.
Czytaj this article o tym, jak skonfigurować serwer źródłowy (aka SrcSrv) integracji na swojej stronie.
Poświęciłem trochę czasu, aby wykonać te kroki dla naszego kodu, a teraz jesteśmy w stanie pobrać plik .dmp z dowolnej wersji naszego oprogramowania w ciągu ostatnich 6 miesięcy ... uzyskać ślad stosu z symbolami ... i zobacz dokładne linie kodu źródłowego w debugerze. Ponieważ kroki są zintegrowane z naszymi zautomatyzowanymi kompilacjami, teraz jest bardzo mało narzutów.
Musiałem napisać niestandardowy indeksator dla ClearCase, ale mają one wcześniejsze dla Perforce, TFS i być może innych.
Warto zauważyć, że obsługa .dmp w VS2005 jest trochę chwiejna .. jest nieco bardziej stabilna w VS2008.
Trzeba także skonfigurować Visual Studio chwycić symbole dla produktów MS stąd oprócz własnego serwera Symbol:
http://msdl.microsoft.com/download/symbols
który jest opisany w kilku miejscach, takich jak na ten Debugging Tools for Windows teren.
Windbg pozwala ustawić ścieżki źródłowe tak jak ścieżki PDB.
To nie jest wystarczająco inteligentne. Testowane (przynajmniej w VS2005) –
Bummer. Debugery SDK (ntsd/cdb/windbg) są wystarczająco inteligentne. – Bruce