STATUS_FILE_CLOSED

STATUS_FILE_CLOSED to kod błędu wskazujący na próbę wykonania operacji na uchwycie pliku, który został już zamknięty.

STATUS_FILE_CLOSED w systemie Windows

STATUS_FILE_CLOSED jest wartością statusu NTSTATUS używaną przez system Windows, gdy operacja wejścia-wyjścia została skierowana do obiektu plikowego, który został już zamknięty. Kod szesnastkowy tego statusu to 0xC0000128. Nie jest to nazwa uszkodzenia konkretnego pliku ani informacja, że plik został usunięty. Komunikat opisuje nieprawidłowy cykl życia uchwytu lub obiektu plikowego wykorzystywanego przez proces, sterownik albo inną warstwę systemu.

Uchwyt pliku jest wartością używaną przez proces do odwoływania się do zasobu otwartego przez system. Samą operację otwarcia wykonują między innymi funkcje Win32, takie jak CreateFile, a następnie uchwyt może zostać przekazany do ReadFile, WriteFile, SetFilePointerEx, DeviceIoControl lub funkcji związanych z operacjami asynchronicznymi. Zamknięcie uchwytu przez CloseHandle kończy możliwość korzystania z niego przez kod, który nie posiada poprawnej, niezależnej kopii uchwytu. Próba dalszego użycia może doprowadzić do wystąpienia STATUS_FILE_CLOSED albo do innego błędu zależnego od aktualnego stanu procesu.

Jak dochodzi do użycia zamkniętego uchwytu

Typową przyczyną jest błąd w zarządzaniu zasobem. Jedna część programu zamyka uchwyt, podczas gdy druga nadal próbuje wykonywać odczyt lub zapis. Taka sytuacja często powstaje w aplikacjach wielowątkowych, gdy wątek obsługujący zakończenie pracy zamyka plik przed zakończeniem operacji wykonywanej przez wątek roboczy. Podobny problem może wystąpić po dwukrotnym wywołaniu procedury zwalniającej zasoby, po przedwczesnym wyjściu z funkcji albo po błędnej obsłudze wyjątków.

Ryzyko zwiększa korzystanie z wejścia-wyjścia asynchronicznego. Zlecenie odczytu lub zapisu może być jeszcze przetwarzane, gdy kod przechodzi do sprzątania i zamyka uchwyt. Samo sprawdzenie, że funkcja zlecająca operację zwróciła wynik, nie zawsze oznacza zakończenie całej operacji, ponieważ w trybie overlapped wynik może zostać odebrany później, na przykład przez GetOverlappedResult. Przed zamknięciem uchwytu aplikacja musi więc prawidłowo zakończyć albo anulować operacje zależne od tego uchwytu i zsynchronizować pracę wszystkich używających go wątków.

Odrębną klasę przypadków stanowią uchwyty kopiowane lub dziedziczone między procesami. Duplikowanie uchwytu za pomocą DuplicateHandle tworzy odwołanie, którego cykl życia trzeba prowadzić niezależnie. Zamknięcie jednej wartości nie powinno być traktowane jako bezpieczne zakończenie korzystania z innej, ale błędna ewidencja uchwytów może doprowadzić do zamknięcia niewłaściwego zasobu. W kodzie korzystającym z obiektów opakowujących uchwyty analogiczny błąd może powstać wtedy, gdy obiekt zostanie zniszczony, a przechowywana w innym miejscu referencja nadal jest używana.

Rozpoznanie problemu w działającej aplikacji

Diagnozę należy rozpocząć od ustalenia, która operacja zwróciła błąd i jaki uchwyt był wtedy używany. Sam wpis STATUS_FILE_CLOSED nie wskazuje jeszcze, czy przyczyną jest błąd aplikacji, sterownika urządzenia, biblioteki obsługującej pliki czy komponentu systemowego. Warto zebrać nazwę procesu, identyfikator wątku, ścieżkę pliku lub urządzenia, kolejność wywołań oraz informację, czy operacja była synchroniczna, czy asynchroniczna. W aplikacji natywnej pomocne jest rejestrowanie momentu utworzenia, przekazania, zakończenia i zamknięcia uchwytu, bez zastępowania uchwytu samą nazwą pliku.

Jeżeli błąd występuje sporadycznie, szczególne znaczenie ma korelacja czasowa między zamknięciem a późniejszym odczytem lub zapisem. Należy sprawdzić ścieżki wyjątków, instrukcje return wykonywane po błędzie, funkcje sprzątające oraz synchronizację mutexami, sekcjami krytycznymi lub zdarzeniami. Przydatne może być śledzenie aktywności plikowej narzędziem rejestrującym operacje procesu, na przykład Process Monitor, a w przypadku własnego kodu także debugowanie z punktami zatrzymania przy CloseHandle i funkcjach wejścia-wyjścia. Trzeba rozróżnić STATUS_FILE_CLOSED od STATUS_FILE_DELETED, ponieważ drugi status dotyczy operacji wykonanej na pliku po jego usunięciu, a nie wyłącznie zamknięcia obiektu.

Postępowanie serwisowe przy błędach operacji plikowych

Na komputerze użytkownika należy najpierw odtworzyć błąd i ustalić, czy dotyczy jednej aplikacji, konkretnego pliku, urządzenia USB, dysku sieciowego czy całego systemu. Jeżeli problem występuje tylko w jednym programie, pierwszeństwo ma kontrola jego aktualizacji, dodatków, bibliotek i sposobu obsługi uchwytów. Jeżeli błąd pojawia się w kilku aplikacjach, analizuje się również sterowniki, system plików, nośnik danych i urządzenia pośredniczące. Nie należy automatycznie uznawać STATUS_FILE_CLOSED za dowód fizycznego uszkodzenia dysku.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, obejmującą diagnostykę problemów z systemem Windows, aplikacjami oraz operacjami odczytu i zapisu. Zakres czynności ustala się na podstawie objawów, logów i wyników testów, a nie na podstawie samego symbolu błędu. W zależności od ustalonej przyczyny rozwiązaniem może być poprawa konfiguracji programu, usunięcie konfliktu sterownika, naprawa komponentów systemu albo wymiana uszkodzonego podzespołu.