P
Du kannst eine Menge Infos von den Systemen einsammeln, auch wenn du nicht "vor Ort" bist.
(1) Remote Debuggen
Dazu muß auf dem remote server zumindest eine Unterstützung intalliert sein, geht nicht "vom USB Stick". dann kannst du dich mit einem beliebigen Prozeß per Intranet verbinden. Ich hab das mal mit VC6 durchgezogen, war aber eine Schinderei.
WinDbg (SDK Tools) brauchst du nicht zu installieren, ist aber halt... sehr rudimentär.
(2) Du kannst für einen Release-Build auch Debug-Informaitonen generieren.
Dazu für den Compiler DebugInfo:Programmdatenbank einstellen, und im Linker "DebugInfo generieren" einschalten. Dann bekommst du separate .pdb-Dateien für deine binaries. Die .pdb's behältst du (zusammen mit den binaries des compile-laufs), nur die binaries lieferst du aus.
(3) Crash-Info einsammeln
Auf allen Systemen bekommst du die zumindest die Basis-Crashinfo (Crash-Adresse, Exception, Stack Trace, Register). Mit den entsprechenden Tools (MSDN) kommst du damit an die Crash-Adresse, und bekommst ziemlich gut raus,
was passiert ist.
Auf einem neueren System bekommst du außerdem einen 64K "MiniDump". Normalerweise wird angeboten, diesen an MS zu senden (wo halt jeder "Don't send" klickt), kannst du in deiner Anwendung aber auch umleiten. Unter VS7 und aufwärts kannst du diesen Minidump importieren, um an die Stelle des Crash zu kommen.
http://www.google.com/custom?q=MiniDump+site%3Acodeproject.com&sitesearch=
Je nach Optimierungseinstellungen brauchst du zwar ein wenig Assemblerkenntnisse, aber das geht oftmals gut. Man kann auch für Testfälle einen "checked build" ohne Optimierungseinstellungen in Reserve halten.
(4) MS gibt dir normalerweise keine Redistribution Licence für die Debug-Laufzeitbibliotheken (nur mal so als Hinweis...)