Debug Symbols

HaJo.

Hallo!

Ich habe mir gerade die Windows Vista SP1 Debug Smbols heruntergeladen und installiert. Weiß jemand wie ich dieses nun Visual Studio 2008 mitteile, dass diese beim Debuggen geladen werden?

Ich habe Sie unter Options->Debbuging->Symbols das Installationsverzeichnis eingetragen "C:\Windows\Symbols" reicht das?

Martin Richter

IMHO ja!
Beim ir ist das Verzeichnis jedoch
C:\Windows\Symbols\dll

Noch besser/einfacher ist es den entsprechenden Symbol Server von MS anzugeben und die "fehlenden" Dateien einfach automatisch laden zu lassen...
http://msdl.microsoft.com/download/symbols

Einfach ein Cache Verzeichnis angeben z.B:
C:\Daten\Symbols

Jochen Kalmbach

Der Symbol-Server ist wirklich einfacher... dann gehen die Debug-Symbole auch, wenn Du Hotfixes installiert hast...
Definiere einfach eine Umgebungsvariable wie folgt:

_NT_SYMBOL_PATH=SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Am einfachsten unter "Systemsteuerung|System|Erweitert|Umgebungsvariablen".

HaJo.

Ich habe nun sowohl die Umgebungsvariable - mein Pfad hat Leerzeichen, scheint aber zu funktoinieren - gesetzt als auch den Server als Quelle in den VS Einstellungen eingegeben.

Heruntergeladen wurden einige Symboldateien. Also scheint es zu funktionieren. Aber Debugausgabefenster steht nur lokale Quellen und auch nichts von meinem Cache Ordner. Werden dennoch alles Symbole korrekt geladen bzw. werden nur Fehler angezeigt?

Jochen Kalmbach

In VS wird eigentlich nicht viel angezeigt... nur ob Symbols geladen wurden (public oder private) oder nicht.
Wenn Du aussagekräftige Infos willst, dann nimm WinDbg. Dort dann z.B.:

0:000> .sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
0:000> !sym noisy
noisy mode - symbol prompts on
0:000> .reload
Reloading current modules
..........
DBGHELP: ntdll - public symbols  
         c:\websymbols\ntdll.pdb\36515FB5D04345E491F672FA2E2878C02\ntdll.pdb
..
0:000> lm
start    end        module name
00400000 00499000   CPP_VS2005   (deferred)             
5d450000 5d4ea000   COMCTL32   (deferred)             
76350000 7639a000   comdlg32   (deferred)             
77be0000 77c38000   msvcrt     (deferred)             
77da0000 77e4a000   ADVAPI32   (deferred)             
77e50000 77ee1000   RPCRT4     (deferred)             
77ef0000 77f37000   GDI32      (deferred)             
77f40000 77fb6000   SHLWAPI    (deferred)             
7c800000 7c907000   kernel32   (deferred)             
7c910000 7c9c7000   ntdll      (pdb symbols)          c:\websymbols\ntdll.pdb\36515FB5D04345E491F672FA2E2878C02\ntdll.pdb
7e360000 7e3f0000   USER32     (deferred)             
7e670000 7ee91000   SHELL32    (deferred)             
0:000> !lmi ntdll.dll
Loaded Module Info: [ntdll.dll] 
         Module: ntdll
   Base Address: 7c910000
     Image Name: ntdll.dll
   Machine Type: 332 (I386)
     Time Stamp: 411096d4 Wed Aug 04 09:57:08 2004
           Size: b7000
       CheckSum: c09c4
Characteristics: 210e  perf
Debug Data Dirs: Type  Size     VA  Pointer
             CODEVIEW    22, 7b6dc,   7aadc RSDS - GUID: {36515FB5-D043-45E4-91F6-72FA2E2878C0}
               Age: 2, Pdb: ntdll.pdb
                CLSID     4, 7b6d8,   7aad8 [Data not mapped]
     Image Type: FILE     - Image read successfully from debugger.
                 C:\WINDOWS\system32\ntdll.dll
    Symbol Type: PDB      - Symbols loaded successfully from symbol server.
                 c:\websymbols\ntdll.pdb\36515FB5D04345E491F672FA2E2878C02\ntdll.pdb
    Load Report: public symbols , not source indexed 
                 c:\websymbols\ntdll.pdb\36515FB5D04345E491F672FA2E2878C02\ntdll.pdb

HaJo.

Jochen Kalmbach schrieb:

In VS wird eigentlich nicht viel angezeigt... nur ob Symbols geladen wurden (public oder private) oder nicht.
Wenn Du aussagekräftige Infos willst, dann nimm WinDbg.

Recht schönen Dank auch.

Martin Richter

Im VS kannst Du im Module-View (Debug-Menu) sehen ob Symbole geladen werden. Dort kann man auch gezielt Symboldateien nachladen.

HaJo.

Martin Richter schrieb:

Im VS kannst Du im Module-View (Debug-Menu) sehen ob Symbole geladen werden. Dort kann man auch gezielt Symboldateien nachladen.

So ganz optimal ist das Verwenden des Microsoft Servers nicht. Es verzeögert trotz Caching den Debug Start ganz schön.

Was müsste ich den eintragen wenn ich die lokalen Symbolen verwenden müsste?

Jochen Kalmbach

Wenn Du die Symbols einmal runtergeladen hast (was Du ja jetzt schon gemeacht hast), dann lass einfach den zweiten Teil weg:

_NT_SYMBOL_PATH=SRV*c:\websymbols

HaJo.

Jochen Kalmbach schrieb:

Wenn Du die Symbols einmal runtergeladen hast (was Du ja jetzt schon gemeacht hast), dann lass einfach den zweiten Teil weg:

Gut, also könnte ich auch den Pfad "C:\Windows\Symbols\dll" des Installationsprogramms anstatt des Cache-Pfades nutzen.

Martin Richter

Ich arbeite nur mit den herunter geladenenen Dateien. Hotfixes und so weiter werden eben mit den Symbol Dateien der Installation nicht abgedeckt.

Und ich mache es wie Jochen, bis zum nächsten Patch-Day oder solange ich keine Crash-Dumps von fremden Rechner analysiere deaktiviere ich den Link auf den MS Server. Das ist mit der neuen UI ganz einfach.
Mit der Environment Variable arbeite ich gar nicht mehr.

Jochen Kalmbach

Das Problem mit dem DOwnload-Pack ist, dass es nur solange Funktioniert, so lange Du *keine* Hotfixes installierst!
Es ist aber davon abzuraten einen Rechner mit Internet ohne Hotfixes zu betreiben... deshalb verwenden ich immer nur den Symbol-Server.

Und wenn er die Symbole einmal gefunden hat, ist es auch nicht mehr langsam. Immer nur beim aller ersten Start, nach einem Hotfix-Update.

Deshalb verstehe ich es auch nicht ganz, warum es bei Dir so viel langsamer sein soll....
Poste doch mal Deine Debug-Ausgabe, wenn der Symbol-Server aktiviert ist...

HaJo.

Also ich schätze ich bin überzeugt und werde es im Einstellungsdialog handlen.
Aber es eigentlich bei jedem Debug-Start neue Symbole heruntergeladen. Wozu benötige ich z.B. bei meinem Programm das WindowsCodecs.pdb Symbol?

Ich werd's dann immer nach dem Patch-Day wieder anhaken und dann wieder weg-haken.

P.S.: Ein Frage zu Crash Dump Files. Kann ich in meiner Anwendung auch welche erzeugen oder werden die automatisch von Windows erzeugt?

Jochen Kalmbach

HaJo. schrieb:

Aber es eigentlich bei jedem Debug-Start neue Symbole heruntergeladen.

Normalerweise versucht er nur Symbole zu laden, die er noch nicht hat. Alle anderen holt er lokal!

HaJo. schrieb:

Wozu benötige ich z.B. bei meinem Programm das WindowsCodecs.pdb Symbol?

Das musst doch Du wissen! Wenn Du diese DLL verwendest, dann wird auch versucht die Symbole dafür zu laden...

HaJo. schrieb:

P.S.: Ein Frage zu Crash Dump Files. Kann ich in meiner Anwendung auch welche erzeugen oder werden die automatisch von Windows erzeugt?

Sowohl als auch.
Wenn Du eine (in einer) Firma bist, dann könnt Ihr Euch bei WINQUAL anmelden, dann bekommt ihr die Dumps, wenn der Kunde einen Absturz via "Bericht senden" an MS geschickt hat.

Ansonsten kannst Du auch InProcess einen Dump schreiben.

Ganz grob:

void Init() 
{ 
  SetUnhandledExceptionFilter(CrashHandlerExceptionFilter); 
} 

static LONG __stdcall CrashHandlerExceptionFilter( 
  EXCEPTION_POINTERS* ep) 
{ 
  const char *szFN = "minidump-file.dmp";
  WriteMiniDumps("minidump-file.dmp", pExPtrs); 
  int ret = -1;  // failed 
  HANDLE hFile; 

  if (hdbghelpmod == NULL) 
    hdbghelpmod = LoadLibrary("dbghelp.dll"); 
  if (hdbghelpmod == NULL) 
    return ret; 

  if (pMDWD == NULL) 
    pMDWD = (tMDWD) GetProcAddress(hdbghelpmod, "MiniDumpWriteDump"); 
  if (pMDWD == NULL) 
    return ret; 

  hFile = CreateFile(szFN, 
    GENERIC_READ | GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 
FILE_ATTRIBUTE_NORMAL, NULL); 

  if (hFile != INVALID_HANDLE_VALUE) 
  { 
    MINIDUMP_EXCEPTION_INFORMATION stMDEI; 
    stMDEI.ThreadId = GetCurrentThreadId(); 
    stMDEI.ExceptionPointers = ep; 
    stMDEI.ClientPointers = TRUE; 
    // try to create an miniDump: 
    if (pMDWD( 
      GetCurrentProcess(), 
      GetCurrentProcessId(), 
      hFile, 
      MiniDumpNormal, 
      &stMDEI, 
      NULL, 
      NULL 
      ) == FALSE) 
    { 
      printf("Minidump failed! 0x8.8X\n", GetLastError()); 
      OutputDebugString("Minidump failed!"); 
    } 
    else 
      ret = 0;  // suceeded 
    CloseHandle(hFile); 
  } 
  return ret; 
}

Siehe aber auch:
http://blog.kalmbachnet.de/?postid=75

HaJo.

Jochen Kalmbach schrieb:

HaJo. schrieb:

Wozu benötige ich z.B. bei meinem Programm das WindowsCodecs.pdb Symbol?

Das musst doch Du wissen! Wenn Du diese DLL verwendest, dann wird auch versucht die Symbole dafür zu laden...

Das ist ja das merwürdige. Ich verwende diese Dll u.a. gar nicht.

Jochen Kalmbach schrieb:

Wenn Du eine (in einer) Firma bist, dann könnt Ihr Euch bei WINQUAL anmelden, dann bekommt ihr die Dumps, wenn der Kunde einen Absturz via "Bericht senden" an MS geschickt hat.

Mit "reichlich" Kleingeld.

Zu den Dump Files. Das werder ich mir mal näher ansehen. In deinem Blog-Beitrag schreibst du u.a., dass das "Ausnahmeverhalten" der CRT seit VS2005 sich geändert hat. Ich hatte dazu bisher immer spradisch etwas gesucht, da im Release Build einige STL Exceptions in MFC Applikationen (nicht nur hier) trotz try/catch nicht gefangen werden, wurde allerdings nicht wirklich fündig. Kann man die Einstellung ändern?

Denn an den try/catch Stellen soll das Programm ja gerade NICHT abschmieren, sondern kann nach einer Fehlermeldung seinen Dienst weiterverrichten.

Jochen Kalmbach

In meinem Blog-Beitrag geht es um das Verhalten von "unhandled Exceptions"! Ab VC2005 können einige dieser Excpetions (z.B. /GS-Fehler) *nicht* mehr selber abgefangen werden, sondern es wird auf jeden Fall das WER aufgerufen! Das finde ich etwas "unschön"...

Was Du meinst ist vermutlich das Verhalten bei "catch(...)", oder?

beeinflussen.

Siehe:
http://msdn2.microsoft.com/en-us/library/1deeycx5

sri

HaJo. schrieb:

Jochen Kalmbach schrieb:

HaJo. schrieb:

Wozu benötige ich z.B. bei meinem Programm das WindowsCodecs.pdb Symbol?

Das musst doch Du wissen! Wenn Du diese DLL verwendest, dann wird auch versucht die Symbole dafür zu laden...

Das ist ja das merwürdige. Ich verwende diese Dll u.a. gar nicht.

Musst Du auch nicht. Es reicht schon, wenn eine von Dir verwendete Systemdatei dieses Modul lädt. Bei WindowsCodecs.dll ist es höchstwahrscheinlich die uxtheme.dll, welche WindowsCodecs.dll verzögert importiert.

Mondmann

Hallole.
Ich häng mich mal gerade hier ein.

Ich experimentiere gerade mit Windbg, mit dem ich noch nicht viel Erfahrung habe.
Grund des Ganzen ist, daß ein Kunden, ca. 1Mal in der Woche einen Absturz hat.
Es dreh sich um einen ISAPI-Dll die im IIS6 geladen ist.
Die DLL reißt dann den Webserver mit und dieser hängt sich auf.
Ich habe Ihm nun einen DLL mit Debuginformationen geschickt.
Gibts dann nen Crash, wird eine entsprechende Meldung angezeigt,oder?
Ist bei mir ja auch so.

Gibts dann noch irgndein *.dmp File?
Soll ich mir das mal schicken lassen?
Nur kann ich das Zeugs nicht wirklich lesen.

Welche Möglichkeiten gibts noch um Fehler auf fremden Systemen aufzuspüren?
Es wird sich ziemlich sicher um ein Speicherleck handeln...

Danke Mondmann

Jochen Kalmbach

Lass auf dem System ein Crash-Dump (minidump) erstellen (wenn er sich aufgehängt hat via ADPlus).
Und dann einfach bei Dir lokal den dmp in WinDbg öffnen und den Fehler (oder callstack) anzeigen lassen...

!analyze -v

Dazu musst Du aber die gleichen pdb/dlls von Dir haben wie auf dem Zielrechner.

Mondmann

Was ist denn ADPlus???
Und was sind die pdb files?