Debug Symbols

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?

Jochen Kalmbach

Du solltest Dich mit der Hilfe zu WinDbg beschäftigen...
http://www.microsoft.com/whdc/devtools/debugging/default.mspx

ADPlus und IIS:
http://support.microsoft.com/kb/286350

Mondmann

Ok, danke.

Mondmann

Hmm..ok. Hast du mir vielleicht noch ein paar Tips?

Habe nun die Debug Tools runtergelade und mit adplus experimentiert.
Habe in meinen Quellcode einen Division duch null eingebaut welche von adplus korrekt aufgezeichnet wurde. (adplus.vbs -iis -crash)
Im Dumpfile steht dann die Extension und die Funktion, sogar der Quellcode wird aufgerufen und die entsprechende Zeile Markiert.

Soweit funktionierts bei mir auf dem Rechner.

Ich musste ja den Pfad zu den MS-Symboldateien angeben (Path) wie hier schon beschrieben.

Wenn ich das jetzt beim Kunden aufzeichnen will, was muss ich machen?

1. Muss er auch diese Umgebungsvariable angeben?(für die Symbole)
2. Reicht das , wenn ich ihm die adplus.vbs Datei schicke oder braucht er die kompletten Debugging Tools?
3. Mit dem *.pdb Dateien kann ich immer noch nichts anfange. Diese werden ja erzeugt, wenn ich die DLL mit Debuginformationen erzeuge.
Nur was steht da drin?
Muss ich die dem Kunden auch mitsenden?

4. Wenn es nun funktioniert und der Kunde sendet mit ein Dumpfile, dann öffne ich die mti windbg.exe und kann dann auch die Funktion rauslesen oder?

Danke Mondmann

Jochen Kalmbach

Mondmann schrieb:

Wenn ich das jetzt beim Kunden aufzeichnen will, was muss ich machen?

1. Muss er auch diese Umgebungsvariable angeben?(für die Symbole)

Nein.

Mondmann schrieb:

2. Reicht das , wenn ich ihm die adplus.vbs Datei schicke oder braucht er die kompletten Debugging Tools?

Gute Frage... musst halt schauen, was ADPlus alles braucht... das brauchst Du dann auch auf dem Zielrechner...

Mondmann schrieb:

3. Mit dem *.pdb Dateien kann ich immer noch nichts anfange. Diese werden ja erzeugt, wenn ich die DLL mit Debuginformationen erzeuge.
Nur was steht da drin?

Das verwendet dann WinDbg um Dir die Zeile anzuzeigen... *Du* musst damit gar nichts machen... sie müssen nur da sein!

Mondmann schrieb:

Muss ich die dem Kunden auch mitsenden?

Nein.

Mondmann schrieb:

. Wenn es nun funktioniert und der Kunde sendet mit ein Dumpfile, dann öffne ich die mti windbg.exe und kann dann auch die Funktion rauslesen oder?

Ja, eben so wie Du es auch bei Dir gemacht hast...

Martin Richter

BTW: Nur um Crashdumps zu laden genügt Dein Visual Studio.

Mondmann

Alles klar, habs schon losgeschickt.
Allerdings hatte ich da Deinen Post noch nicht gelesen und dern Kunden veranlasst die Umgebungsvariable zu setzten.
Grund ist, daß bei mir adplus aufs Internet zugreifen will..auf den Symbol Server von ms..dann wird er das beim Kunden wohl auch wollen...
Naja, bin mal hier sehr Dankbar für die Tips(vor allem mit ADPLus)
der Absturz tritt ca. 1x wöchentlich auf..so lange muss er es halt mitlaufen lassen...

Jochen Kalmbach

Martin Richter schrieb:

BTW: Nur um Crashdumps zu laden genügt Dein Visual Studio.

Sagen wir mal so: Nur um simple Crashdumps zu laden genügt VS

Martin Richter

Jochen Kalmbach schrieb:

Martin Richter schrieb:

BTW: Nur um Crashdumps zu laden genügt Dein Visual Studio.

Sagen wir mal so: Nur um simple Crashdumps zu laden genügt VS

Was sind komplexe Crashdumps?

Jochen Kalmbach

Martin Richter schrieb:

Was sind komplexe Crashdumps?

z.B.:
- Kernel-Dumps
- Mixed-Mode User Dumps

Mondmann

So, ich hab nun den Crashdump vom Kunden.
Leider kann ich daraus nichts erkennbares ablesen.
Als ich bei mir hier einen Fehler Provoziert habe, hat der Crashdump mir die Funktion, sogar die Zeile des Fehlers angezeigt.
In dem Crashdump vom Kunden steht nichts.
Lediglich:

Datei:

PID-6312__W3WP.EXE_-ActiconAppPool-__1st_chance_Process_Shut_Down__full_1e68_2008-04-17_15-49-59-747_18a8.dmp

Dump:

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=7c947c0f edi=fffffffe
eip=7c9485ec esp=0006fe18 ebp=0006ff0c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
7c9485ec c3 ret

Bei der Zweitletzten Zeile stand bei mir meine Funktion
Hier steht ntdll!KiFastSystemCallRet
Was auch immer das bedeuten mag.
Schätze, in dieser DLL wird wohl kein Fehler vorhanden sein, da ja nur meine Applikation abstürzt.

Datei:

PID-6820__DLLHOST.EXE_System_Application__1st_chance_CONTRL_C_OR_Debug_Break__mini_079c_2008-04-21_10-41-57-074_1aa4.dmp

Dump:

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
eax=7ffda000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c93a3e1 esp=009dffcc ebp=009dfff4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
Unable to load image C:\WINDOWS\system32\ntdll.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntdll.dll
ntdll!DbgBreakPoint:
7c93a3e1 cc int 3

Datei:

PID-8080__INETINFO.EXE__1st_chance_CONTRL_C_OR_Debug_Break__mini_17c8_2008-04-21_10-41-41-886_1f90.dmp

This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
eax=7ffdd000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c93a3e1 esp=013bffcc ebp=013bfff4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
Unable to load image C:\WINDOWS\system32\ntdll.dll, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntdll.dll
ntdll!DbgBreakPoint:
7c93a3e1 cc int 3

Datei:

PID-10148__W3WP.EXE_-DefaultAppPool-__1st_chance_Process_Shut_Down__full_15a0_2008-04-18_20-08-23-877_27a4.dmp

Dump:

eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=7c947c0f edi=fffffffe
eip=7c9485ec esp=0006fe18 ebp=0006ff0c iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246
ntdll!KiFastSystemCallRet:
7c9485ec c3 ret

Was fange ich nun mit dem Crashdump an und wie gehts nun weiter?
Kann da jemand etwas rauslesen?

Was auch komisch ist:
Das größte Dumpfile hat 21MB..stehen aber nur ein paar Zeilen drin...

Jochen Kalmbach

Wie gesagt:
- Du brauchst die *passende* PDB-Datei für die EXE, die der Kunde hatte!
- Du musst den Pfad zur PDB-Datei richtig einstellen (.sympath+ Pfad_Zur-PDB-Datei)
- Du musst teilweise auch den Pfad zum Image (EXE) richtig einstellen; d.h. Du benötigst auch die passende EXE vom Kunden)

Du kannst auch alternativ mir die PDB/EXE/DMP zukommen lassen, dann mach ich es mal hier bei mir...

Mondmann

Jochen Kalmbach schrieb:

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.

Die habe ich...aber wie und wo führe ich das !analyze -v aus?

sri

Es sollte eigentlich auch reichen, die EXE vom Kunden samt dazu passender PDB-Datei sowie die DMP-Datei in ein Verzeichnis zu kippen und die DMP-Datei dann mit VS 2005/2008 zu öffnen und F5 zu drücken. Zumindestens klappt das bei mir immer so.