''Czarna skrzynka'' rejestruje pracę aplikacji i odtwarza jej działanie w sytuacjach awaryjnych.

W idealnym świecie, w aplikacjach nie występują błędy. Program działa zgodnie z oczekiwaniami, a użytkownik kontaktuje się z dostawcą wyłącznie w sprawie zakupu nowej wersji. Rzeczywistość jest bardziej ponura: aplikacja nie ma pełnej funkcjonalności, której klient oczekiwał, zawiera błędy, jest trudna w obsłudze, kosztuje więcej niż zakładano.

Ten ponury scenariusz to wynik konstatacji, że realnej aplikacji o złożonej funkcjonalności nie da się wyczerpująco przetestować. Istnieją teoretyczne metody sprawdzenia poprawności aplikacji, ale w literaturze przedmiotu cytuje się tylko jeden udany przypadek programu teoretycznie poprawnego: jest to program do obsługi działania metra w Paryżu. Można by się również spodziewać, że programy do obsługi sond kosmicznych będą odporne na błędy, ale zdarzały się już wypadki, że oprogramowanie zawodziło.

Za każdym razem inaczej

Usuwanie błędów w trakcie pisania i kompilowania programów to zajęcie żmudne i nie lubiane przez większość programistów. Co gorsza, w przypadku programów z dynamicznie ładowanymi bibliotekami DLL nie istnieje stałe miejsce ich wgrywania do pamięci; zależnie od konfiguracji komputera wgrywane są do różnych jej obszarów. W efekcie, nawet jeśli program testujący wskaże miejsce pojawienia się błędu, to przy próbie powtórzenia operacji, komunikat debuggera będzie już inny.

Wobec niemożności wyczerpującego przetestowania aplikacji przez programistów trzeba się liczyć z koniecznością usuwania błędów na miejscu, u użytkowników. Tu można stosować trzy strategie.

Pierwsza polega na dostarczeniu aplikacji "zinstrumentalizowanej", zawierającej wbudowane przez kompilator części kodu przeznaczone wyłącznie do testowania i usuwania błędów. Po wystąpieniu sytuacji awaryjnej, te części kodu zapisują na dysku informacje: miejsce wystąpienia awarii czy adres w pamięci itp. Aby usunąć błąd, trzeba przeanalizować ogromną liczbę linii kodu i ustalić czynnik odpowiedzialny za jego powstanie. Wady takiego rozwiązania to: spowolnione działanie aplikacji (często więcej niż dziesięciokrotnie) i znaczące zwiększenie jej rozmiaru.

Druga strategia to przystosowanie aplikacji do korzystania z zewnętrznych narzędzi analizujących jej działanie i zapisujących informacje o sytuacjach nietypowych i awaryjnych.

Trzecia polega na tym, aby nic nie robić! W wielu przypadkach można ją uzasadnić niewielkim rozmiarem aplikacji, a w przypadku projektów wewnętrznych - obecnością programistów na miejscu. Jest to jednak strategia najgorsza, gdyż w razie pojawienia się błędów podważa zaufanie użytkowników do informatyki.

Zdalne poprawianie aplikacji

Współczesne kompilatory C/C++ pozwalają na zdalne usuwanie błędów w aplikacji. Na przykład w Visual C++ istnieją specjalne biblioteki (zdalne jądro debuggera), które można swobodnie dystrybuować z aplikacją. Aplikacje uruchomione na komputerze użytkownika umożliwiają zdalny dostęp do niej ze standardowego debuggera, tak jakby działały one lokalnie. Jest to jednak rozwiązanie niechętnie przyjmowane przez klientów. Pozbawia ich bowiem kontroli nad aplikacją. Jednocześnie ryzykują oni, że dostęp poprzez sieć do danych uzyskają osoby nieupoważnione.

Izraelska firma Mutek opracowała rozwiązanie Software BlackBox Flight Recorder działające na podobnej zasadzie, jak czarne skrzynki w samolotach. BlackBox, działający w tle, zapisuje informacje o działaniu aplikacji na dwóch poziomach: systemowym i kodu (zarówno w klienckich, jak i serwerowych częściach aplikacji). W razie awarii może odtworzyć scenariusz, by usunąć błąd.

Na poziomie systemowym program koncentruje się na zewnętrznych, widzialnych zdarzeniach i działaniach. Oznacza to wszystkie operacje dyskowe, zawartość ekranu, kanały komunikacyjne, połączenia sieciowe, procesy, wątki itp. Informacje te są szczególnie przydatne dla administratorów systemu i aplikacji. Poziom kodu dotyczy wewnętrznego działania aplikacji i jest używany przez programistów do zapisywania, odtwarzania i wskazywania problemów, aż do poziomu poszczególnych linii kodu. Działanie BlackBoxu jest podobne do operacji typowego debuggera, ale w przeciwieństwie do niego, nie wymaga wiadomości pomocniczych ani zmian w kodzie aplikacji.