Unter Vista und Windows 7 ist es ganz einfach in den WER Einstellungen Einträge vorzunehmen, mit denen man mit nur ein paar Registry Einträgen sofort zu Minidumps kommt.

Nachfolgend die Registry Einträge, die einen Fulldump im Verzeichnis %LOCALAPPDATA%\CrashDumps erzeugen.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps]
"DumpType"=dword:00000001
"DumpCount"=dword:00000010
"DumpFolder"=hex(2):25,00,4c,00,4f,00,43,00,41,00,4c,00,41,00,50,00,50,00,44,\
00,41,00,54,00,41,00,25,00,5c,00,43,00,72,00,61,00,73,00,68,00,44,00,75,00,\
6d,00,70,00,73,00,00,00

Eine vollständige Liste der Einstellungen findet sich in der MSDN Doku:
http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx

PS:
Ich benutze diese Einstellungen aktuell auch einem Bug in VisualStudio 2010 auf die Spur zu kommen, damit ich Crashdumps regelmässig an http://connect.microsoft.com übertragen kann.

PPS: (14.01.2011 nach Hinweis von André)
Wie man auch der Doku ennehmen kann ist fpr dieses Funktion Vista SP1, Windows 2008 Server oder Windows 7 notwendig. Vista RTM hat diese Funktion nicht.

Leider funktionierte dies bei mir nicht sofort. Ich bekam die folgende Fehlermeldung:

TF248015: Your work item query could not be completed due to an unexpected error returned by the Microsoft SQL Server Full-text engine. Contact your system administrator to check the Application event log for Team Foundation Server.

Na fein Also muss ich mich selbst kontaktieren weil irgendwas mit der Volltext Suche nicht klappt.

Nach einigem hin und her irren durch alle möglichen Einstellungen entdeckte ich den Missetäter: Der “SQL Full-text Filter Daemon Launcher” war nicht gestartet. Dies ist ein Dienst, den man in der Computer-Verwaltung oder dem SQL-Server-Konfigurations-Manager findet.
Aus irgend einem mysteriösen Grund war hier ein falsches Dienstkonto angegeben und der Dienst konnte nicht starten.

Nachdem das korrigiert war habe ich danach noch ein Rebuild des Warehouse veranlasst damit die Indizes sofort zur Verfügung aktuell sind. Das erfolgt über die folgende Web Adresse: http://servername:8080/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx 
in dem man ProcessWarehouse auswählt. Unter collectionName gibt man seine Team Project Collection an um die es geht. Wer die Namen der Collections vergessen hat, findet sie in der Team Foundation Server Administration Console aufgelistet.

Eigentümlicherweise startete der Service nicht. Die Init Funktion meldete immer, dass die Requirements nicht gegeben wären. Was eigentlich nicht sein kann, weil der selbe Code in einem anderen Kontext eines GUI Programms perfekt funktioniert.

Ein wenig debuggen zeigte, dass die Common Control 6.0 nicht gefunden wurden.
Eigentlich kein Wunder. Der Service hat keine UI, es gibt keinen Code der die Common Control 6.0 verwendet, allerdings hatte meine DLL ja ein entsprechendes Manifest für die Common Control 6.0 DLL.
Aber der Versionstest in der DLL lädt immer die 5er Version, also die Version ohne Manifest.

Es dauerte eine Weile bis es bei mir klingelte und ich verstand worin das Problem lag:

• Wenn man ein Manifest in einer DLL mit dem Code 2 einträgt (ISOLATIONAWARE_MANIFEST_RESOURCE_ID), dann funktioniert dieses Manifest wenn in diesem Moment die ComCtl32.dll implizit geladen werden sollte.
• In meinem Fall aber klappte das nicht. Die DLL wurde nicht implizit geladen. Die Versionkontrolle später führte LoadLibrary direkt durch und führte dann DllGetVersion aus (mit GetProcAddress ermittelt).
• In meinem Fall bedeutet das aber, das LoadLibrary im Aktivierungskontext (Activation Context) der EXE ausgeführt wird, und die hat kein ComCtl32 Manifest für die Version 6.0. Es ist ja auch nur ein Service.
• Damit es funktioniert muss man in jedem Fall auch den folgenden Define setzen.

#define ISOLATION_AWARE_ENABLED 1

• oder man muss dafür sorgen, dass man seinen eigenen Aktivierungskontext nutzt. Sprich seine Manifeste, die man selber möchte.
• Durch diesen define, werden bestimmte Funktionen wie CreateWindow, LoadLibrary, CoCreateInstance, SendMessage und andere durch einen inline-Code ersetzt der einen Aktivierungkontext benutzt und die aktuellen Manifeste der DLL bestimmt und benutzt.

In meinem Fall hieß die Lösung nicht LoadLibrary zu benutzen sondern GetModuleHandle und wenn eben ComCtl32 gar nicht im Speicher ist, also auch nicht benutzt wird auch keinen weiteren Test durchzuführen, aber zur Sicherheit habe ich auch ISOLATION_AWARE_ENABLED gesetzt.

Siehe auch:
http://msdn.microsoft.com/en-us/library/aa376607(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa375197(VS.85).aspx

http://one.org/de/schneller/index.html

Zumindest für ein Kind in der Welt kann man mit einem Euro am Tag für eine gesicherte Schulausbildung, Ernährung und Gesundheitsfürsorge sorgen. Was sich mit diesem Euro für Kinder verändern kann ist unfassbar für uns Mitteleuropäer.

Wen das mehr interssiert, der sollte sich mal http://www.compassion-de.org ansehen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

On Error Resume Next
If MyFunction() Then
    MsgBox "MyFunction succedded"
Else
    MsgBox "MyFunction failed"
End If
 
MsgBox "... continue execution ..."
 
Function MyFunction
    MsgBox "Start MyFunction"
    On Error Goto 0
    ' Just a failure here
    i = 1/0
    MsgBox "End MyFunction"
    Test = true
End Function

ist, dass bei einem Fehler in der Funktion MyFunction die Funktion sofort abgebrochen wird. Nach diesem Fehler wird aber als nächste Zeile der Then Block ausgeführt. Die Funktion läuft also in den Bock “MyFunction succeeded” was nicht unbedingt im Sinne des Erfinders wäre.

Der Entwickler hat zwei Dinge nicht bedacht:

1. Er wollte, das ein Fehler in MyFunction das Skript terminiert. Das erreicht er aber nicht. MyFunction wird bei einem Fehler abgebrochen, aber On Error Resume Next im nächsten äußeren Scope behandelt den Fehler.
2. Dem Entwickler war unklar, dass On Error Resume Next bei einem Fehler in einem If Statement zum Ausführen des Then Blocks führt
   Und man kann sich Denken was passiert wenn man eine While MyFunction() Schleife hat? Jaaaaa genau! Wird in MyFunction ein Fehler ausgelöst hat man eine perfekte Endlosschleife!

Am Besten also die Funktion nicht im If-Statement ausführen sondern das Ergebnis in einer Variable Speichern. Sofern die Variable zuvor empty war, ist sie es im Falle ein Fehlers hinterher auch, d.h. sie wird nicht verändert. Nach der Funktion kann man dann zusätzlich auch Err.Number prüfen.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

On Error Resume Next
Result = MyFunction()
If Result Then
    MsgBox "MyFunction succedded"
Else
    MsgBox "MyFunction failed"
End If
 
MsgBox "... continue execution ..."
 
Function MyFunction
    MsgBox "Start MyFunction"
    On Error Goto 0
    ' Just a failure here
    i = 1/0
    MsgBox "End MyFunction"
    Test = true
End Function

Und was lernen wir daraus
On Error Resume Next ist tückisch und sollte möglichst sofort zurückgesetzt werden und schon gar nicht über den Scope einer eigenen Funktion hinaus verwendet werden.

Bei der Umstellung auf die neue 11er Version musste ich auf den Clients die alte Software entfernen.
Bei den Rechnern mit einer zentralen Installation wusste ich natürlich das Kennwort für die Deinstallation, denn das wurde von mir eingerichtet und lag im Password Safe.
Allerdings wurden scheinbar auch einige Clients von anderen Admins von CD aus installiert. Hier war mir nun unklar, was für ein Deinstallations Kennwort verwendet wird.

Nach einigem Suchen im Netz bekam ich drei Wege heraus die Corporate Edition zu entfernen:

• Das Standardkennwort lautet bei einer nicht verwalteten Installation symantec
• Man kann die Abfrage des Kennwortes bei der Deinstallation aber auch verhindern, indem man den Registryschlüssel UseVPUninstallPassword in HKLM\Software\Intel\LANDesk\VirusProtect6\CurrentVersion\AdministrtatorOnly\Security von 1 auf 0 umsetzt.
• Symantec selbst bietet auf der Homepage eine komplizierte Beschreibung für die manuelle Deinstallation.
• Nicht versucht habe ich das Norton Removal Tool, dass es auch gibt.

Jeder C/C++ Entwickler hat schon Meldungen dieser Art beim Testen seiner Programme gesehen:

HEAP[CrashTest.exe]: Heap block at 006D7920 modified at 006D79B0 past requested size of 88
Windows has triggered a breakpoint in CrashTest.exe.
This may be due to a corruption of the heap, which indicates a bug in CrashTest.exe or any of the DLLs it has loaded. 

oder etwas in dieser Art:

Debug Error!
Program: …nts\Visual Studio 2008\Projects\CrashTest\Debug\CrashTest.exe
HEAP CORRUPTION DETECTED: after Normal block (#110) at 0x000D7948.
CRT detected that the application wrote to memory after end of heap buffer.

Ursache ist ein Fehler wie in diesem kleinen Beispielprogramm:

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <windows.h>
#include <tchar.h>
#include <crtdbg.h>
int _tmain(int argc, _TCHAR* argv[]) 
{ 
  char *pCorrupt = new char[100];
  ZeroMemory(pCorrupt,106); // -- This will corrupt the heap 
  char *pOther = new char[100]; 
  ZeroMemory(pOther,100); 
  delete [] pOther; 
  delete [] pCorrupt; 
  return 0; 
}

Wenn die Debug-CRT benutzt wird erhält man automatisch einen Break im Debugger wenn der Speicherblock pCorrupt freigeben wird (Zeile 11). Man braucht also nur den Call-Stack oder Stacktrace anzusehen und kann zumindest feststellen, welcher Block defekt ist.

Schwieriger wird es dann schon die Stelle zu finden, an der der Block überschrieben wird. In meinem Beispiel also die Zeile 7. Besonders dann wird es komplex, wenn das Programm größer ist, und der Speicherblock an evtl. sehr vielen Stellen genutzt wird.

Um die Position einzugrenzen und nicht evtl. bis zum Programmende warten zu müssen, wenn man (hoffentlich) alle Objekte freigibt kann man die CRT veranlassen den Heap zu prüfen. Dies geschieht mit _CrtCheckMemory oder AfxCheckMemory.
Streut man also in seinem Code an strategisch guten Stellen das folgende Statement in seinen Code

ASSERT(AfxCheckMemory()); // oder _CrtCheckMemory

kann man relativ gut die Stelle einkreisen die den Fehler verursacht, und das ohne große Performanceverluste. Man erhält sofort einen ASSERT, ab dem Moment ab dem die Integrität des Heaps zerstört wurde und der Check durchgeführt wird.

Noch etwas einfacher ist es, die CRT dazu zu bringen sich sofort zu melden wenn der Heap zerstört wird. Dies kann man erreichen indem man das Debug-Flag _CRTDBG_CHECK_ALWAYS_DF setzt.

Platziert man bei Programmstart die folgende Codezeile in seinem Programm

_CrtSetDbgFlag(_CrtSetDbgFlag(0)|_CRTDBG_CHECK_ALWAYS_DF);

dann unterbricht die CRT das Programm sofort bei der nächsten Allokation eines Speicherbocks, nachdem der Heap zerstört wurde. In meinem Beispiel also direkt bei der nächsten Allokation in Zeile 8!
Nachteil ist, dass bei jeder Allokation der Heap geprüft wird und damit die Performance schon in den Keller gehen kann, wenn das Programm groß ist und der Fehler evtl. selten auftritt.

Man kann also mit den einfachen Bordmitteln der CRT einen Fehler schon relativ leicht eingrenzen.

Soweit für heute. Was man noch alles machen kann um effektiv Heap-Fehler zu finden werde ich demnächst noch in weiteren Artikeln zu diesem Thema beschreiben.

—————————
Microsoft Visual C++ Debug Library
—————————
Debug Assertion Failed!

Program: …\Debug\TestSDIScrollView.exe
File: f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\viewscrl.cpp
Line: 385

For information on how your program can cause an assertion
failure, see the Visual C++ documentation on asserts.

(Press Retry to debug the application)
—————————
Abbrechen   Wiederholen   Ignorieren  
—————————

Der Grund liegt darin, dass in der MFCNext Implementierung schon sehr früh ein RedrawWindow ausgeführt wird wenn das Main Window maximiert wird. In diesem Fall wird OnDraw/OnPaint bereits ausgeführt wenn SetScrollSizes noch nicht aufgerufen wurde. Das geschieht ja normalerweise meistens erst in OnInitialUpdate.
Dieser ASSERT soll dem Programmierer darauf hinweisen, dass SetScrollSizes unabdingbar für die korrekte Funktion des CScrollView notwendig ist.
Leider ist in diesem alten Code ein Seiteneffekt nicht berücksichtigt worden, der durch MFCNext in Spiel kam.

Das Ganze lässt sich jedoch einfach umschiffen indem man im Konstruktor seines Views vorab SetScrollSizes mit Dummywerten aufruft. Die eigentliche Initialisierung mag dann später wie gewohnt in OnInitialUpdate erfolgen.

CScriptEditorView::CScriptEditorView()
{
  // If the program is launched maximized, a RedrawWindow occurs in a very
  // early stage and OnDraw would be called without an initialized mapping mode
  // So we just do a dummy init here.
  SetScrollSizes(MM_TEXT,CSize(0,0));
}

Besonders stark finde ich Abschnitt (3) bzgl. der fliegenden Schweine

BTW: Eine Liste aller 1. April RFCs gibt es hier
http://www.apps.ietf.org/rfc/apr1list.html