Windows (slownik)

Parametr -File nie działa z dodatkowymi parametrami w PowerShell wskazuje na błędne cudzysłowowanie argumentów przekazywanych do skryptu — cały ciąg trzeba poprawnie ująć w cudzysłowy.

Sytuacja, w której .NET działa wyłącznie z uprawnieniami administratora, zwykle wskazuje na niewłaściwe uprawnienia do katalogu instalacyjnego środowiska lub na blokadę w ustawieniach zabezpieczeń — poprawne działanie z konta standardowego wymaga skorygowania uprawnień NTFS.

.NET Framework 3.5 (obejmujący też 2.0 i 3.0) w nowszych systemach Windows jest komponentem opcjonalnym pobieranym z internetu podczas instalacji — brak połączenia z Windows Update lub zablokowane zasady grupowe najczęściej uniemożliwiają jego instalację.

Uszkodzony .NET Framework 4.8 objawia się błędami uruchamiania aplikacji korzystających z tego środowiska. Naprawia się go przez wbudowane narzędzie naprawy .NET Framework Repair Tool lub reinstalację komponentu z poziomu funkcji opcjonalnych Windows.

Brak działania .NET Framework najczęściej wynika z uszkodzonych plików komponentu, niekompletnej instalacji aktualizacji lub konfliktu wersji — diagnozuje się to sprawdzając listę zainstalowanych wersji w funkcjach opcjonalnych Windows i logi instalatora.

Problemy z .NET na Hyper-V najczęściej dotyczą maszyn wirtualnych z niekompletną instalacją komponentów systemowych lub ograniczeniami zasobów przydzielonych maszynie wirtualnej, wpływającymi na czas uruchamiania środowiska.

Po aktualizacji Windows .NET może przestać działać, jeśli aktualizacja nadpisała lub usunęła pliki komponentu — naprawia się to przez ponowną instalację lub naprawę .NET Framework z listy funkcji opcjonalnych.

Przywrócenie systemu (System Restore) do punktu sprzed instalacji .NET może cofnąć również pliki tego komponentu, mimo że aplikacje wciąż oczekują jego obecności — rozwiązaniem jest ponowna instalacja .NET po przywróceniu.

W kontenerach Docker .NET wymaga odpowiedniego obrazu bazowego zgodnego z wersją aplikacji (runtime, aspnet czy sdk) — błędy zwykle wynikają z niedopasowania wersji obrazu do wymagań aplikacji.

Wersje Windows N (bez wbudowanych komponentów multimedialnych, wymagane w UE) mogą powodować błędy w aplikacjach .NET korzystających z frameworków multimedialnych — rozwiązaniem bywa doinstalowanie Media Feature Pack.

Windows Server Core (bez interfejsu graficznego) obsługuje ograniczony zestaw funkcji .NET — komponenty wymagające GUI (jak WPF) nie działają w tym wariancie systemu z założenia, niezależnie od wersji .NET.

Problemy .NET z IIS zwykle dotyczą niezainstalowanego modułu ASP.NET Core Module (dla nowszych wersji .NET) lub niewłaściwie skonfigurowanej puli aplikacji w Menedżerze IIS.

Tryb S systemu Windows dopuszcza uruchamianie wyłącznie aplikacji ze Sklepu Microsoft — klasyczne środowisko .NET Framework instalowane spoza sklepu nie uruchomi się w tym trybie bez wcześniejszego przełączenia na pełny Windows.

W środowisku korporacyjnym .NET Runtime bywa blokowany przez zasady grupowe (Group Policy) ograniczające instalację komponentów lub przez oprogramowanie zabezpieczające blokujące wykonywanie niepodpisanych bibliotek.

Brak zainstalowanego .NET Runtime uniemożliwia uruchomienie aplikacji, które go wymagają — rozwiązaniem jest pobranie i zainstalowanie odpowiedniej wersji (.NET 6/7/8 itd.) bezpośrednio ze strony Microsoftu, dopasowanej do architektury systemu.

Microsoft regularnie wycofuje wsparcie dla starszych wersji .NET (kończy się dla nich okres aktualizacji zabezpieczeń) — aplikacje oparte na wycofanej wersji dalej działają, ale wymagają migracji na nowszą wersję runtime dla bezpieczeństwa.

.NET SDK, który nie uruchamia się z powodu zablokowanych zależności, zwykle sygnalizuje brakujące komponenty (np. workloady) lub konflikt wersji SDK zainstalowanych równolegle — polecenie "dotnet --info" pozwala zdiagnozować, która wersja jest aktywna.

Gdy .NET SDK nie wykrywa projektów, przyczyną bywa niezgodność wersji w pliku global.json z zainstalowanymi SDK lub uszkodzona struktura katalogu projektu — sprawdzenie "dotnet --list-sdks" pokazuje dostępne wersje.

Brak zainstalowanego .NET SDK uniemożliwia kompilację i budowanie aplikacji .NET (w odróżnieniu od samego Runtime, który tylko je uruchamia) — SDK trzeba pobrać osobno ze strony Microsoftu.

Niektóre komponenty .NET SDK (np. narzędzia z interfejsem graficznym do projektów WPF/WinForms) wymagają pełnego środowiska graficznego systemu — na serwerach bez GUI (Server Core) ich uruchomienie kończy się błędem.

\\adres_IP działający tylko tymczasowo wskazuje na dynamiczny adres przydzielany przez DHCP, zmieniający się po odnowieniu dzierżawy.

\\adres_IP\folder działający oznacza, że łączność sieciowa jest sprawna, a problem leży w rozpoznawaniu nazw (DNS/NetBIOS), nie w samym udziale.

\\adres_IP\udział działający potwierdza sprawność protokołu SMB i uprawnień — problem dotyczy wyłącznie rozpoznawania nazwy hosta.

\\nas-name niedziałające wskazuje na problem z rozpoznawaniem nazwy urządzenia — spróbuj połączyć się bezpośrednio przez adres IP.

\\nazwa_komputera niedziałające wskazuje na problem z rozpoznawaniem nazw DNS lub NetBIOS w sieci lokalnej.

\\nazwa_komputera\folder niedziałające wskazuje na tę samą przyczynę — rozpoznawanie nazwy hosta, przy sprawnej łączności IP.

\\nazwa_urządzenia\udział niedziałające wskazuje na problem z rozpoznawaniem nazwy lub brak uprawnień dostępu do udostępnionego zasobu.

\\wsl$\Ubuntu niedziałające w Eksploratorze wskazuje na zatrzymaną dystrybucję WSL lub uszkodzoną integrację sieciową podsystemu Linux.

Zmienna %ALLUSERSPROFILE% powinna wskazywać na katalog danych wspólnych dla wszystkich użytkowników (domyślnie C:\ProgramData). Gdy wskazuje na inną, nieistniejącą lub przeniesioną lokalizację, instalatory programów zapisujące tam dane kończą się błędem — najczęściej po ręcznej zmianie tej zmiennej w rejestrze lub po migracji profilu na inny dysk.

Zmienna %APPDATA% powinna wskazywać katalog danych aplikacji bieżącego użytkownika (C:\Users\[nazwa]\AppData\Roaming). Niepoprawne jej rozpoznanie zwykle wynika z uszkodzonego profilu użytkownika w rejestrze (klucz ProfileList) lub z profilu tymczasowego załadowanego po błędzie logowania.

Zmienna %COMSPEC% domyślnie wskazuje na C:\Windows\System32\cmd.exe. Jeśli wskazuje na nieistniejący plik, oznacza to zwykle ręczną (błędną) modyfikację tej zmiennej systemowej lub uszkodzenie samego pliku cmd.exe — programy wywołujące wiersz poleceń przestają wtedy działać.

Zmienna %HOMEPATH% wskazuje katalog domowy użytkownika względem dysku z %HOMEDRIVE%. Przy profilu tymczasowym (ładowanym po nieudanym logowaniu do profilu stałego) wartość ta bywa nieprawidłowa lub pusta, bo system nie mapuje jej do właściwego katalogu użytkownika.

Zmienna %LOCALAPPDATA% (C:\Users\[nazwa]\AppData\Local) w trybie awaryjnym Windows bywa niedostępna dla niektórych usług i sterowników, ponieważ tryb awaryjny ładuje jedynie minimalny zestaw komponentów systemu — część aplikacji korzystających z tej ścieżki po prostu się nie uruchamia.

Gdy zmienna %PATH% nie zawiera ścieżki do katalogu systemowego (np. C:\Windows\System32), polecenia systemowe wywoływane z wiersza poleceń przestają być rozpoznawane. Naprawia się to przywracając brakujący wpis w zmiennych środowiskowych systemu (Panel sterowania → Zaawansowane ustawienia systemu).

Jeśli %PATH% nie zawiera ścieżki do pliku wykonywalnego konkretnego programu, uruchomienie go z wiersza poleceń bez podania pełnej ścieżki kończy się błędem "nie jest rozpoznawany jako polecenie". Rozwiązaniem jest dopisanie właściwego katalogu do zmiennej PATH.

Uszkodzona zmienna %PATH%, która ładuje się tylko częściowo, zwykle wynika z przekroczenia limitu długości albo z błędu podczas jej edycji (np. usunięcia średnika rozdzielającego wpisy). Poprawia się ją, odtwarzając pełną listę ścieżek w edytorze zmiennych systemowych.

Wpisy w zmiennej %PATH% muszą być rozdzielone średnikiem. Nieprawidłowe separatory (np. przecinek albo brak separatora) powodują, że system nie potrafi poprawnie odczytać kolejnych ścieżek — efektem jest brak rozpoznawania części programów z wiersza poleceń.

Windows ma praktyczny limit długości zmiennej %PATH% (historycznie ok. 2047 znaków w cmd.exe). Po jego przekroczeniu nowo dopisywane ścieżki są ucinane i programy z nich się nie uruchamiają — rozwiązaniem jest usunięcie zbędnych, nieaktualnych wpisów.

Zmienna %ProgramFiles% w 64-bitowym Windows wskazuje katalog programów 64-bitowych, a osobna zmienna %ProgramFiles(x86)% — programów 32-bitowych. Błędy pojawiają się, gdy starszy skrypt lub instalator odwołuje się tylko do %ProgramFiles% oczekując ścieżki 32-bitowej.

Zmienna %SystemRoot% powinna wskazywać główny katalog instalacji Windows (domyślnie C:\Windows). Błędna wartość zwykle wynika z uszkodzonego rejestru systemowego lub z próby uruchomienia systemu z nietypowej lokalizacji (np. po klonowaniu dysku bez odpowiedniej aktualizacji ścieżek rozruchowych).

Zmienna %TEMP% (podobnie %TMP%) powinna wskazywać istniejący katalog plików tymczasowych użytkownika. Gdy wskazuje na nieistniejący katalog — np. po ręcznym usunięciu folderu Temp — instalatory i część aplikacji zgłaszają błędy zapisu i kończą działanie.

Zmienna %USERNAME% pobierana jest z aktualnie zalogowanego konta systemowego. Jej nieprawidłowe działanie zwykle wskazuje na uszkodzony profil użytkownika lub na uruchomienie procesu w kontekście innego konta (np. SYSTEM) niż oczekiwane przez skrypt czy aplikację.

Zmienna %USERPROFILE% powinna wskazywać katalog domowy zalogowanego użytkownika (C:\Users\[nazwa]). Wskazywanie na zły folder zwykle oznacza załadowanie profilu tymczasowego lub uszkodzenie klucza rejestru ProfileList przypisującego ścieżkę do identyfikatora SID konta.

12V_RAIL_FAULT to zgłoszenie błędu na linii zasilania 12V zasilacza — najczęstsza przyczyna niestabilnej pracy lub braku uruchomienia komputera, wymagająca sprawdzenia zasilacza multimetrem i, w razie potwierdzenia usterki, jego wymiany.

3V3_RAIL_FAULT to zgłoszenie błędu na linii zasilania 3,3V zasilacza, odpowiedzialnej m.in. za zasilanie części układów płyty głównej — jego niestabilność objawia się losowymi zawieszeniami lub brakiem startu komputera.

5V_RAIL_FAULT to zgłoszenie błędu na linii zasilania 5V zasilacza — nieprawidłowe napięcie na tej linii może powodować problemy z rozpoznawaniem dysków i urządzeń USB, zasilanych właśnie napięciem 5V.

AC_ADAPTER_FAILURE to błąd zgłaszany przez system, gdy zasilacz (adapter prądu zmiennego) przestaje być prawidłowo rozpoznawany lub dostarcza nieprawidłowe parametry zasilania — wymaga sprawdzenia samego zasilacza i gniazda ładowania w laptopie.

AC_ADAPTER_INCOMPATIBLE oznacza, że podłączony zasilacz nie spełnia wymaganej przez laptop mocy lub napięcia — typowo po użyciu zasilacza od innego, słabszego modelu. Rozwiązaniem jest użycie zasilacza o parametrach zgodnych z danym laptopem.

AC_ADAPTER_NOT_RECOGNIZED oznacza, że laptop nie rozpoznaje podłączonego zasilacza jako oryginalnego lub zgodnego — może to być usterka układu identyfikacji zasilania na płycie głównej albo uszkodzenie samego zasilacza czy jego wtyku.

ACPI (Advanced Configuration and Power Interface) to standard komunikacji między systemem operacyjnym a firmware płyty głównej, odpowiedzialny za zarządzanie energią, stanami uśpienia, temperaturą i rozpoznawaniem urządzeń — większość usterek związanych z uśpieniem czy baterią ma swoje źródło właśnie w warstwie ACPI.

Gdy ACPI blokuje przejście systemu w stan uśpienia S3, przyczyną zwykle jest sterownik lub urządzenie zgłaszające sprzeciw wobec uśpienia (można to sprawdzić poleceniem powercfg /requests) albo nieprawidłowa implementacja ACPI w BIOS-ie danego modelu płyty głównej.

Awaria jądra systemu (ntoskrnl.exe) powiązana z ACPI zwykle wskazuje na błąd w tabelach ACPI dostarczonych przez firmware płyty głównej lub konflikt sterownika zarządzania energią — pierwszym krokiem diagnozy jest aktualizacja BIOS-u do najnowszej wersji.

Awaria sterownika acpi.sys to poważny błąd na poziomie jądra systemu, zwykle wynikający z niekompatybilnego firmware płyty głównej lub uszkodzonych plików sterownika — wymaga aktualizacji BIOS-u lub, w skrajnych przypadkach, naprawy systemu.

Ogólny brak działania ACPI diagnozuje się sprawdzając Podgląd zdarzeń (dziennik systemowy) pod kątem błędów źródła "ACPI", oraz aktualność wersji BIOS-u płyty głównej, która implementuje tabele ACPI odczytywane przez system.

Ogólna niesprawność warstwy ACPI (Advanced Configuration and Power Interface) objawia się błędnym zarządzaniem zasilaniem, temperaturą lub przerwaniami sprzętowymi — Menedżer urządzeń pokazuje wtedy żółty wykrzyknik przy „Microsoft ACPI-Compliant System” lub podobnym węźle.

W maszynach wirtualnych hypervisor udostępnia gościowi uproszczoną, emulowaną tablicę ACPI (bez pełnych metod _PSS/_TSS), więc funkcje zależne od rzeczywistego sprzętu — np. skalowanie napięcia czy zaawansowane stany uśpienia — mogą nie działać mimo poprawnie zainstalowanego sterownika.

Problem najczęściej nie wynika z edycji Windows 10 Home jako takiej, lecz z tego, że producent laptopa dostarczył tablice ACPI (DSDT/SSDT) zoptymalizowane pod fabrycznie preinstalowany system — po czystej instalacji Home część metod ACPI bywa nierozpoznawana.

Sterownik ACPI Battery (acpiec/CmBatt) nie ładuje się dla kontrolera baterii, przez co system nie pokazuje poziomu naładowania ani stanu podłączenia zasilacza — zwykle po aktualizacji BIOS-u lub uszkodzeniu deskryptora _BIF/_BST w firmware.

Gdy tablica ACPI nie eksponuje poprawnie stanu S4, opcja hibernacji jest wyszarzona lub próba jej użycia kończy się natychmiastowym wybudzeniem — typowo przy wyłączonym w BIOS-ie wsparciu dla hibernacji lub konflikcie ze sterownikiem grafiki hybrydowej.

Niektóre firmware nie implementują metody ACPI pozwalającej systemowi przechwycić i zmienić domyślne działanie przycisku zasilania (np. na „zapytaj co zrobić”), więc naciśnięcie przycisku zawsze wymusza twarde wyłączenie niezależnie od ustawień w Panelu sterowania.

Brak lub uszkodzenie metody ACPI odpowiedzialnej za stan S3 sprawia, że opcja „Uśpij” w menu zasilania jest niedostępna albo komputer po wybraniu jej natychmiast się wybudza — częste na sprzęcie wymuszającym wyłącznie Modern Standby.

Wake-on-LAN wymaga, by tablica ACPI zgłaszała kartę sieciową jako urządzenie zdolne do wybudzania systemu (flaga PME) — jeśli firmware tego nie udostępnia, opcja „Zezwalaj temu urządzeniu na wybudzanie komputera” jest wyszarzona mimo wsparcia karty.

Kontrolery USB-C podłączone przez tunel Thunderbolt bywają opisane w ACPI jako osobna gałąź PCI, której system nie wiąże poprawnie z portem fizycznym — peryferia (dock, monitor, karta sieciowa) są wtedy niewidoczne mimo poprawnego podłączenia.

Wybudzanie przyciskiem zasilania po uśpieniu zależy od metody ACPI _PRW powiązanej z danym urządzeniem — jeśli firmware jej nie eksponuje lub deskryptor jest uszkodzony, system pozostaje w stanie niskiego poboru mocy mimo naciśnięcia przycisku.

Gdy kontroler ACPI nie odczytuje danych z układu SMBus/EC obsługującego baterię, Windows zgłasza „Brak baterii wykrytej” mimo fizycznie sprawnego akumulatora — zwykle po aktualizacji BIOS-u lub reflashu embedded controllera.

System nie rozpoznaje podłączenia zasilacza jako zdarzenia ACPI (brak wyzwolenia GPE), więc ikona zasilania pokazuje „Nie ładuje” lub „Brak baterii” mimo fizycznie działającego adaptera — częsty objaw uszkodzonego embedded controllera.

Brak deskryptora ACPI dla przycisku zasilania (\_SB.PWRB) powoduje, że system nie reaguje na krótkie naciśnięcie przycisku żadną akcją — pomaga zwykle aktualizacja firmware lub reset ustawień embedded controllera.

Metoda ACPI odpowiedzialna za raportowanie obecności zasilacza (AC Adapter, ACPI0003) nie zwraca poprawnego statusu, więc system pokazuje pracę na baterii mimo podłączonego zasilania sieciowego.

Sterownik ACPI nie rejestruje zdarzeń w dzienniku Kernel-Power/ACPI Podglądu zdarzeń, co utrudnia diagnozę problemów z uśpieniem czy termiką — zwykle po wyłączeniu logowania WMI-ACPI lub uszkodzeniu tablicy zdarzeń GPE.

ACPI zgłasza się jako nieaktywny, gdy firmware nie eksponuje żadnego stanu uśpienia poza S0 — typowe dla urządzeń z wymuszonym Modern Standby, na których klasyczne S1–S3 zostały świadomie usunięte z tablicy DSDT.

W trybie S0 Low Power Idle system formalnie nie „śpi”, lecz utrzymuje ograniczoną aktywność procesora i sieci — jeśli sterowniki nie wspierają tego trybu poprawnie, ACPI raportuje się jako nieaktywny, a bateria rozładowuje się szybciej niż przy klasycznym uśpieniu.

Przy uruchomieniu w trybie Legacy/CSM zamiast UEFI część funkcji ACPI (np. szybki rozruch, zaawansowane zarządzanie energią) jest niedostępna, bo system operuje na starszym interfejsie zgodności zamiast pełnej tablicy ACPI UEFI.

Zmiana języka interfejsu może uszkodzić powiązania w rejestrze między sterownikiem ACPI a jego lokalizowanymi komunikatami (pliki MUI), co bywa mylnie odczytywane jako awaria samego ACPI — problem znika po naprawie pakietu językowego.

Nowsze wymagania Secure Boot i TPM 2.0 zakładają konkretną wersję tablicy ACPI (m.in. obecność TPM2 ACPI table) — starszy firmware bez jej aktualizacji zgłasza niezgodność, blokując pełną funkcjonalność zabezpieczeń sprzętowych.

Błędnie obsłużone przerwanie ACPI (np. przy zmianie jasności czy zdarzeniu doku) potrafi zawieszać wątek odpowiedzialny za powiadomienia systemowe, co objawia się powtarzającymi się awariami explorer.exe niezwiązanymi z samym plikiem powłoki.

Część firmware wykonuje długie procedury inicjalizacji ACPI (np. testy pamięci NVRAM) już po zakończeniu POST, co wydłuża czas do pojawienia się logo Windows o kilka–kilkanaście sekund bez żadnego komunikatu błędu.

Nieprawidłowa metoda ACPI _PTS/_WAK wywoływana przy zamykaniu systemu może wymusić pełny restart zamiast wyłączenia — typowy objaw niekompatybilnego BIOS-u po aktualizacji Windows zmieniającej sposób zamykania (Fast Startup).

Błędnie skonfigurowany procesor przerwań ACPI (np. zbyt częste odpytywanie czujnika termicznego) obciąża jeden rdzeń procesu System, co widać w Menedżerze zadań jako stałe kilkanaście procent zużycia CPU bez wyraźnej przyczyny.

Cykliczne resetowanie się kontrolera ACPI zwykle wskazuje na niestabilne napięcie z układu embedded controller lub uszkodzony kondensator na płycie głównej — objawia się powtarzającym się krótkim „mrugnięciem” ekranu i ponownym wykrywaniem urządzeń.

Producenci laptopów z certyfikatem Modern Standby konfigurują firmware tak, by tablica ACPI zawsze zgłaszała wyłącznie stan S0 — użytkownik nie ma wtedy możliwości przywrócenia klasycznego uśpienia S3 bez modyfikacji BIOS-u lub jego brak w ogóle nie jest wspierany.

Firmware może na stałe wymuszać tryb S0 Low Power Idle i jednocześnie usuwać z tablicy DSDT deskryptor stanu S3, co w praktyce blokuje klasyczne uśpienie nawet po ręcznej zmianie w rejestrze (klucz CsEnabled).

Niektórzy producenci celowo blokują w firmware dostęp do części funkcji ACPI (np. zmianę profili energetycznych) poza własną aplikacją narzędziową, co ogranicza możliwości systemowego zarządzania energią.

Uszkodzona lub źle skompilowana tablica DSDT potrafi zwracać niepoprawne wartości sensorów (temperatura, napięcie), co Windows odbiera jako błędne dane ACPI i loguje ostrzeżenia w dzienniku System bez realnego wpływu na stabilność.

ACPI_BIOS_FATAL_ERROR to krytyczny błąd zatrzymania systemu (blue screen) wskazujący, że firmware BIOS/UEFI dostarczył systemowi nieprawidłowe lub uszkodzone dane ACPI — najskuteczniejszym rozwiązaniem jest aktualizacja BIOS-u do wersji naprawiającej ten błąd.

Bugcheck ACPI_BIOS_FATAL_ERROR wywołany przez sam sterownik ACPI (acpi.sys) najczęściej oznacza, że firmware zwrócił dane niezgodne ze specyfikacją ACPI podczas inicjalizacji — pomaga aktualizacja BIOS-u do wersji naprawiającej zgodność z tablicami Microsoftu.

Ten sam bugcheck wywołany błędną konfiguracją pamięci wskazuje zwykle na niezgodność map pamięci ACPI (E820) z rzeczywistym układem RAM — typowy po instalacji modułów pamięci o innej geometrii niż zakładał producent płyty.

ACPI_DRIVER_INTERNAL to błąd wewnętrzny sterownika ACPI, zwykle powiązany z niezgodnością między systemem a implementacją ACPI konkretnej płyty głównej — diagnoza obejmuje sprawdzenie dziennika zdarzeń i aktualizację BIOS-u.

ACPI_ERROR to ogólny kod błędu związany z warstwą ACPI, wymagający sprawdzenia konkretnych okoliczności jego wystąpienia w Podglądzie zdarzeń, by ustalić, czy przyczyną jest firmware, sterownik czy konflikt sprzętowy.

ACPI_HAL_MEMORY_MAPPING_ERROR wskazuje na błąd w mapowaniu pamięci między warstwą HAL (Hardware Abstraction Layer) a ACPI — typowo związany z uszkodzonymi lub przestarzałymi tabelami ACPI w BIOS-ie, naprawiany aktualizacją firmware.

ACPI_HARDWARE_RESPONSE_TIMEOUT oznacza, że sprzęt nie odpowiedział w oczekiwanym czasie na zapytanie warstwy ACPI — może wskazywać na usterkę konkretnego podzespołu (np. kontrolera zasilania) lub niestabilne taktowanie ustawione w BIOS-ie.

ACPI_POWER_TRANSITION_FAILED oznacza nieudaną próbę zmiany stanu zasilania (np. przejścia w uśpienie lub wybudzenia) — zwykle wynika z niezgodności sterownika urządzenia z żądanym stanem energii.

ACPI_WAKE_ALARM_FAILURE to błąd mechanizmu budzika systemowego (Wake Alarm), odpowiedzialnego za zaplanowane wybudzanie komputera — zwykle wynika z niezgodności BIOS-u z funkcją zaplanowanego wybudzania w systemie.

ACPI.SYS_DRIVER_CRASH to kod błędu wskazujący na awarię sterownika acpi.sys w jądrze systemu — zwykle wymaga aktualizacji BIOS-u płyty głównej lub sterowników chipsetu, ponieważ sam sterownik systemowy rzadko jest bezpośrednią przyczyną.

acpidump niedziałające poprawnie wskazuje na brak uprawnień administratora lub niekompatybilność narzędzia z konkretną implementacją firmware.

ACTIVE_EX_WORKER_THREAD_TERMINATION to błąd zatrzymania systemu związany z nieprawidłowym zakończeniem wątku roboczego jądra — zwykle wskazuje na wadliwy sterownik, rzadziej na uszkodzoną pamięć RAM, i wymaga analizy zrzutu pamięci, by wskazać winny komponent.

ActiveX to starsza technologia Microsoftu umożliwiająca osadzanie interaktywnych komponentów w przeglądarce i aplikacjach — dziś w dużej mierze wycofana ze względów bezpieczeństwa; błędy z nią związane dotyczą głównie starszych, firmowych aplikacji wewnętrznych.

Błąd polecenia Add-Computer (dołączenie komputera do domeny Active Directory) zwykle wynika z braku uprawnień konta, niedostępności kontrolera domeny w sieci lub nieprawidłowej nazwy DNS domeny.

Polecenie PowerShell Add-LocalGroupMember dodaje użytkownika do lokalnej grupy systemowej (np. Administratorzy) — błędy przy jego użyciu zwykle wynikają z braku uprawnień administracyjnych uruchomionej sesji PowerShell.

Nieosiągalny adres IP zdalnego komputera w sieci lokalnej diagnozuje się poleceniem ping oraz sprawdzeniem zapory sieciowej, poprawności adresacji i fizycznego połączenia sieciowego po obu stronach.

Zablokowany przez system adres MAC zwykle wynika z filtrowania adresów MAC skonfigurowanego na routerze lub w zasadach zabezpieczeń sieci firmowej — odblokowanie wymaga zmiany tej konfiguracji po stronie sieci.