Błąd 0xC004F06C — Znacznik czasu żądania jest nieprawidłowy

Błąd 0xC004F06C — Znacznik czasu żądania jest nieprawidłowy

Błąd 0xC004F06C pojawia się najczęściej podczas procesu, jakim jest aktywacja Windows, gdy system nie może poprawnie zweryfikować czasu żądania wysyłanego do serwera aktywacyjnego. Dotyczy to przede wszystkim środowisk korzystających z KMS, ale problem może wystąpić także po zmianie ustawień daty, strefy czasowej lub po przywracaniu systemu. Jeśli aktywacja nie przechodzi mimo poprawnego klucza produktu, warto zacząć właśnie od sprawdzenia zegara systemowego, źródła synchronizacji czasu i sposobu licencjonowania, np. MAK lub KMS.

Na przestrzeni 2025–2026 roku błąd ten zyskał na znaczeniu wraz z upowszechnieniem Windows 11 24H2 i 25H2, gdzie zaostrzono weryfikację znaczników czasowych w scenariuszach hybrydowych Azure AD Join. Organizacje migrujące do Office 2024 LTSC oraz Exchange Server SE coraz częściej raportują konflikty czasu między kontrolerami domeny a stacjami roboczymi.

Co oznacza błąd 0xC004F06C

Kod 0xC004F06C oznacza, że znacznik czasu żądania aktywacyjnego został uznany za nieprawidłowy. W praktyce system Windows lub serwer KMS wykrywa zbyt dużą różnicę czasu między urządzeniem użytkownika a serwerem, z którym odbywa się aktywacja. Najczęściej granica tolerancji wynosi zaledwie 5 minut, dlatego nawet pozornie drobne odchylenie może przerwać proces.

Mechanizm weryfikacji czasu działa dwutorowo: klient dołącza do żądania lokalny znacznik czasu, a serwer porównuje go ze swoim zegarem. Jeśli różnica przekracza próg tolerancji, serwer odrzuca żądanie, zwracając właśnie 0xC004F06C. W Windows 11 24H2 i 25H2 Microsoft dodatkowo wprowadził sprawdzanie integralności łańcucha czasu — system bada, czy znacznik nie został cofnięty, co jest szczególnie istotne przy przywracaniu snapshotów maszyn wirtualnych.

Komunikat zwykle pojawia się w formie:

• 0xC004F06C
• The KMS determined that the request timestamp is invalid
• Znacznik czasu żądania jest nieprawidłowy

Problem dotyczy przede wszystkim:

• Windows 10 (wersje 21H2, 22H2)
• Windows 11 (wersje 23H2, 24H2, 25H2)
• Windows Server 2019, 2022, 2025

Główne przyczyny

• Nieprawidłowa data lub godzina ustawiona ręcznie w systemie.
• Zła strefa czasowa po migracji komputera, reinstalacji lub zmianie regionu (szczególnie istotne dla firm z oddziałami w różnych krajach UE, gdzie różnica czasu między Warszawą a Lizboną to 2 godziny).
• Brak synchronizacji z serwerem czasu NTP.
• Duża różnica czasu między komputerem a serwerem KMS — częste po przeniesieniu laptopa między strefami czasowymi bez restartu.
• Problemy z usługą czasu systemu Windows (w32time).
• Aktywacja wykonywana po przywróceniu obrazu systemu, snapshotu lub kopii VM — hypervisor może przywrócić czas maszyny do stanu sprzed snapshotu.
• Użycie niewłaściwego modelu licencjonowania, np. próba aktywacji KMS zamiast MAK — dotyczy szczególnie organizacji z mieszanym środowiskiem, gdzie część stacji używa MAK, a część KMS.
• Błędnie wpisany klucz produktu lub nieodpowiedni klucz dla danej edycji systemu.
• W środowiskach AD DS — rozsynchronizowanie czasu między kontrolerem domeny a stacją roboczą przekraczające próg Kerberos (domyślnie 5 minut).

Metody rozwiązania

Metoda 1: Sprawdź datę, godzinę i strefę czasową

Najpierw upewnij się, że system pokazuje poprawny czas lokalny. W Windows wejdź w Ustawienia > Czas i język > Data i godzina i włącz automatyczne ustawianie czasu oraz strefy czasowej. Jeśli komputer był długo offline albo został sklonowany z innej maszyny, ręczne poprawienie czasu bywa konieczne.

W Windows 11 24H2 i 25H2 opcje te znajdują się w dokładnie tej samej ścieżce, jednak Microsoft dodał wizualny wskaźnik stanu synchronizacji — zielona kropka oznacza poprawną synchronizację, pomarańczowa ostrzega o odchyleniu powyżej 1 minuty.

Po korekcie uruchom ponownie komputer i spróbuj aktywacji jeszcze raz.

Metoda 2: Wymuś synchronizację czasu w CMD

Uruchom Wiersz polecenia jako administrator i wykonaj:

w32tm /resync

Jeżeli usługa czasu nie działa poprawnie, możesz ją ponownie uruchomić:

net stop w32time
net start w32time
w32tm /resync

W środowiskach domenowych warto dodatkowo wskazać kontroler domeny jako źródło czasu:

w32tm /config /syncfromflags:domhier /update
net stop w32time && net start w32time
w32tm /resync

Dla maszyn w workgroup, które nie widzą kontrolera domeny, można wskazać publiczny serwer NTP:

w32tm /config /manualpeerlist:"time.google.com,0x9" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync

Ta metoda jest najskuteczniejsza wtedy, gdy błąd 0xC004F06C wynika wyłącznie z rozjazdu zegara względem źródła czasu lub serwera KMS.

Metoda 3: Zweryfikuj kanał aktywacji i ponów aktywację

Jeśli system powinien być aktywowany przez KMS, sprawdź, czy aktywacja przebiega poprawnym kanałem. Następnie uruchom:

slmgr /ato

Warto też sprawdzić szczegóły licencji:

slmgr /dlv

Polecenie slmgr /dlv pokaże, czy system korzysta z licencji KMS, MAK albo Retail, oraz ułatwi ustalenie, czy problem wynika z czasu, czy z nieprawidłowego typu aktywacji.

Metoda 4: Wprowadź ponownie klucz produktu

Jeżeli masz licencję MAK lub indywidualny klucz produktu, wpisz go ponownie i dopiero potem aktywuj system:

slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr /ato

To ważne szczególnie wtedy, gdy komputer był wcześniej skonfigurowany pod KMS, a teraz ma być aktywowany inną metodą. W takim scenariuszu sam poprawny czas nie zawsze wystarczy — system może nadal próbować odnaleźć serwer KMS w sieci, ignorując klucz MAK, dopóki nie zostanie on jawnie wgrany przez slmgr /ipk.

Metoda 5: Sprawdź status aktywacji i datę ważności

Na końcu zweryfikuj, czy system został aktywowany i czy licencja jest rozpoznawana poprawnie:

slmgr /xpr
slmgr /dli

slmgr /xpr pokaże, czy system jest aktywowany trwale, a slmgr /dli poda podstawowe informacje o licencji. Jeśli po tych krokach nadal widzisz błąd, warto rozważyć kontakt z pomocą techniczną lub skorzystanie z dedykowanego klucza dopasowanego do konkretnej edycji systemu.

Metoda 6: Usuń i ponownie zainstaluj klucz KMS

Dla środowisk czysto KMS-owych, gdzie powyższe metody nie pomogły:

slmgr /upk
slmgr /cpky
slmgr /ipk <klucz_GVLK_dla_twojej_edycji>
slmgr /ato

/upk odinstalowuje obecny klucz produktu, a /cpky czyści go z rejestru. Następnie wgrywasz właściwy klucz GVLK (Generic Volume License Key) dla swojej edycji i ponawiasz aktywację.

Metoda 7: Naprawa usługi licencjonowania

Gdy błąd utrzymuje się mimo poprawnych ustawień czasu i klucza, problem może leżeć po stronie uszkodzonych plików licencjonowania:

net stop sppsvc
cd %windir%\ServiceProfiles\NetworkService\AppData\Roaming\Microsoft\SoftwareProtectionPlatform
ren tokens.dat tokens.bak
net start sppsvc
slmgr /ato

Usługa SPP (Software Protection Platform) odtworzy plik tokens.dat przy kolejnej próbie aktywacji. Pamiętaj, że ta operacja wymaga ponownego wprowadzenia klucza produktu.

Diagnostyka

Aby ustalić faktyczną przyczynę, sprawdź problem w tej kolejności:

1. Porównaj datę i godzinę komputera z aktualnym czasem lokalnym.
2. Zweryfikuj strefę czasową oraz ustawienia automatycznej synchronizacji.
3. Uruchom slmgr /dlv i sprawdź, czy system oczekuje aktywacji przez KMS, czy przez MAK.
4. Wykonaj w32tm /resync i zobacz, czy system zgłasza błąd usługi czasu.
5. Jeśli komputer działa w domenie lub środowisku firmowym, sprawdź synchronizację z kontrolerem domeny albo serwerem KMS.
6. Jeżeli problem wystąpił po klonowaniu VM lub przywróceniu backupu, załóż, że zegar systemowy mógł zostać cofnięty.
7. W środowiskach Hyper-V / VMware sprawdź, czy wyłączona jest synchronizacja czasu między hostem a gościem za pośrednictwem hypervisora (tzw. Time Synchronization Integration Service), która może kolidować z w32time.

W praktyce błąd 0xC004F06C bardzo często jest objawem, a nie główną przyczyną. Źródłem problemu może być polityka czasu w domenie, błędna konfiguracja maszyny wirtualnej albo nieprawidłowy kanał aktywacji Windows.

Scenariusze rzeczywiste

Firma księgowa z oddziałami w UE

Średniej wielkości biuro rachunkowe z siedzibą w Warszawie i oddziałem w Barcelonie. Księgowi obu lokalizacji pracują na Windows 11 24H2 Pro, korzystając z Office 2024 LTSC Professional Plus do wystawiania faktur VAT 23% oraz obsługi KSeF. Firma posiada umowę Volume Licensing z kluczami MAK.

Problemy zaczęły się po wymianie połowy floty na nowe ThinkPady T14 Gen 5 z preinstalowanym Windows 11 24H2. Pracownicy hiszpańskiego oddziału, podróżujący między biurami, zgłaszali błąd 0xC004F06C przy próbie aktywacji po powrocie do Polski. Diagnostyka wykazała, że systemy po locie zachowywały strefę czasową CEST (Madryt), a synchronizacja NTP nie nadążała z korektą przed próbą aktywacji MAK — różnica wynosiła 62 minuty. Rozwiązaniem było wdrożenie GPO wymuszającego w32tm /resync przy każdym logowaniu użytkownika oraz przełączenie na automatyczne wykrywanie strefy czasowej.

Koszt przestoju pojedynczego stanowiska księgowego w szczycie sezonu rozliczeniowego oszacowano na 450 PLN/h — przy czterech stanowiskach problem oznaczał stratę 1800 PLN w ciągu jednej godziny, zanim wdrożono poprawkę.

Deweloper z wieloma snapshotami VM

Zespół programistyczny w Krakowie pracuje na maszynach wirtualnych Windows Server 2025 pod Hyper-V, z licencjami aktywowanymi przez firmowy serwer KMS. W cyklu testowym deweloperzy regularnie przywracają snapshoty maszyn sprzed 2-3 dni.

Po każdym przywróceniu snapshotu aktywacja KMS kończyła się błędem 0xC004F06C. Przyczyną było cofnięcie zegara VM do stanu z momentu wykonania snapshotu — różnica 48-72 godzin powodowała odrzucenie znacznika czasu przez serwer KMS. Windows 11 25H2 (wersja serwerowa) dodatkowo wykrywał cofnięcie łańcucha czasu jako potencjalny atak rollback. Rozwiązaniem było dodanie skryptu w32tm /resync jako pierwszego kroku po przywróceniu snapshotu, przed jakąkolwiek próbą aktywacji.

Uczelnia z mieszanym środowiskiem MAK/KMS

Politechnika w Gdańsku zarządza 1200 stacjami — część na licencjach MAK (laboratoria specjalistyczne), reszta przez KMS (ogólnodostępne pracownie). Podczas corocznej reinstalacji systemów w wakacje, technicy przypadkowo wgrali obraz przygotowany pod KMS na 30 maszyn w laboratorium MAK. Mimo poprawnego czasu, aktywacja MAK zwracała 0xC004F06C, ponieważ system próbował odnaleźć serwer KMS zamiast autoryzować się przez klucz MAK. Rozwiązaniem było uruchomienie slmgr /ipk z właściwym kluczem MAK, a następnie slmgr /ato.

Prewencja

Aby uniknąć podobnych problemów w przyszłości:

• pozostaw włączoną automatyczną synchronizację czasu,
• nie zmieniaj ręcznie daty i godziny bez wyraźnej potrzeby,
• po przywróceniu systemu lub VM zawsze sprawdzaj czas przed aktywacją,
• upewnij się, że używasz właściwego typu licencji: KMS, MAK lub Retail,
• przechowuj poprawny klucz produktu i dokumentację licencyjną,
• w środowisku firmowym skonfiguruj GPO wymuszające synchronizację NTP przy starcie systemu,
• na hostach Hyper-V i VMware wyłącz integracyjną synchronizację czasu, pozostawiając ją wyłącznie usłudze w32time wewnątrz gościa,
• dokumentuj, które maszyny korzystają z MAK, a które z KMS — szczególnie w organizacjach powyżej 100 stanowisk.

Konfiguracja GPO dla wymuszenia synchronizacji czasu

W edytorze zasad grupy (gpmc.msc) skonfiguruj:

1. Computer Configuration > Administrative Templates > System > Windows Time Service > Time Providers > Configure Windows NTP Client
2. Ustaw NTPServer na time.google.com,0x9 lub adres firmowego kontrolera domeny.
3. Włącz Enable Windows NTP Client.
4. Dla Type ustaw NTP.

Dodatkowo przez preferencje rejestru (lub startup script) wymuś w32tm /resync przy każdym uruchomieniu komputera, szczególnie na laptopach często przemieszczających się między strefami czasowymi.

Częste pytania

Dlaczego błąd 0xC004F06C pojawia się po przywróceniu kopii zapasowej VM?

Snapshot lub backup maszyny wirtualnej zapisuje stan zegara systemowego z momentu jego wykonania. Po przywróceniu czas jest cofnięty o godziny lub dni, co serwer KMS interpretuje jako nieprawidłowy znacznik czasu. Rozwiązaniem jest natychmiastowe wykonanie w32tm /resync przed próbą aktywacji.

Czy ten błąd dotyczy tylko KMS, czy także aktywacji MAK i Retail?

Błąd 0xC004F06C najczęściej dotyczy aktywacji przez KMS, ponieważ to serwer KMS porównuje znaczniki czasu. Jednak może wystąpić również przy MAK i Retail, gdy system Windows lokalnie wykryje, że jego zegar drastycznie odbiega od oczekiwanego — szczególnie w Windows 11 24H2/25H2, gdzie dodano walidację łańcucha czasu.

Czy mogę całkowicie wyłączyć sprawdzanie czasu przy aktywacji?

Nie. Weryfikacja znacznika czasu jest integralną częścią protokołu aktywacyjnego i nie można jej pominąć. Jedynym rozwiązaniem jest zapewnienie poprawnej synchronizacji czasu przed aktywacją.

Jaka jest granica tolerancji czasu przy aktywacji Windows?

Standardowa tolerancja wynosi 5 minut między klientem a serwerem KMS. W przypadku aktywacji przez Internet (MAK/Retail) tolerancja może być nieco większa, ale Microsoft nie publikuje dokładnych wartości — najlepiej zakładać te same 5 minut.

Czy zmiana strefy czasowej wystarczy, czy trzeba też synchronizować czas?

Sama zmiana strefy czasowej zmienia tylko wyświetlany czas lokalny, ale nie koryguje rzeczywistego zegara systemowego. Jeśli zegar sprzętowy (RTC) jest przesunięty, konieczna jest synchronizacja NTP. W Windows 11 25H2 system sam ostrzega, gdy różnica między czasem lokalnym a NTP przekracza 1 minutę.

Co zrobić, gdy w32tm /resync zwraca błąd "The computer did not resync"?

Ten błąd oznacza, że usługa czasu nie może połączyć się z żadnym serwerem NTP. Sprawdź dostępność portu UDP 123 na firewallu, poprawność adresu serwera NTP w rejestrze (HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters) i uruchom w32tm /config /update przed ponowną synchronizacją.

Czy aktywacja Windows 11 Pro wymaga innego podejścia niż Windows Server 2025?

Mechanizm błędu 0xC004F06C jest identyczny niezależnie od edycji — różnica leży wyłącznie w kluczach GVLK dla KMS oraz w ścieżce aktywacji (online MAK vs. sieciowy KMS). Procedura diagnostyki i naprawy czasu jest taka sama. Dla wersji Professional szczególnie ważne jest, aby używać klucza dopasowanego dokładnie do swojej edycji — klucz do Windows 11 Home nie aktywuje wersji Pro.

Czy błąd może wystąpić po aktualizacji z Windows 10 do Windows 11?

Tak, szczególnie przy migracji z Windows 10 22H2 do Windows 11 24H2. Proces aktualizacji może zresetować konfigurację usługi czasu lub zmienić kanał aktywacji. Po aktualizacji zawsze warto sprawdzić slmgr /dlv i w razie potrzeby ponowić aktywację.

Jak błąd 0xC004F06C wpływa na Office 2024 LTSC aktywowany przez KMS?

Office 2024 LTSC Professional Plus korzysta z tego samego mechanizmu KMS co Windows — jeśli czas na stacji roboczej jest przesunięty, aktywacja zarówno systemu, jak i pakietu Office zakończy się błędem. W firmach używających Office 2024 LTSC z fakturami VAT (stawka 23%) i integracją KSeF, przestój spowodowany dezaktywacją Office może przekładać się na realne straty finansowe — pojedyncza godzina braku dostępu do faktur oznacza niemożność wystawienia i wysyłki dokumentów do KSeF.

Gdzie kupić sprawny klucz, jeśli obecny ciągle wywala błąd?

Jeżeli diagnostyka potwierdziła, że problem nie leży po stronie czasu ani konfiguracji, źródłem błędu może być uszkodzony lub zablokowany klucz produktu. W takiej sytuacji warto sięgnąć po nowy, sprawny klucz — w ofercie kluczesoft.pl/klucze-windows-11 znajdziesz aktywacyjne klucze do Windows 11 Professional oraz Enterprise z natychmiastową dostawą na e-mail.