[TR] Windows 11 Güncellemesi Sonrası Mavi Ekran veya LSASS.exe Çökmesi: “STATUS_IMAGE_CHECKSUM_MISMATCH”

Windows 11 23H2 veya 24H2 sürümlerinde büyük bir toplu güncelleme sonrasında bazı sistemlerde beklenmedik açılış sorunları görülebilir. Cihaz normal şekilde başlıyor gibi görünse de açılış sırasında mavi ekrana düşebilir, kullanıcı oturum açtıktan kısa süre sonra yeniden başlayabilir veya lsass.exe süreci çökerek sistemi kararsız hale getirebilir.

Bu senaryoda Event Viewer üzerinde LSA, WinInit, Device Guard, Credential Guard veya güvenlik bileşenleriyle ilişkili kayıtlar görülebilir. Bazı durumlarda hata kodu olarak aşağıdaki ifade karşımıza çıkar:

STATUS_IMAGE_CHECKSUM_MISMATCH

Bu hata genellikle sistemin kritik bir sürücü, DLL veya güvenlik bileşeni ile ilgili bütünlük problemi algıladığını gösterir. Microsoft dokümantasyonunda STATUS_IMAGE_CHECKSUM_MISMATCH hata kodunun 0xC0000221 değerine karşılık geldiği ve bir sürücü ya da sistem DLL dosyasının bozulmuş olabileceğini ifade ettiği belirtilir. Ayrıca disk, RAM veya pagefile gibi I/O yolundaki donanımsal sorunlar da bu hatayı tetikleyebilir.

Sorunun Genel Belirtileri

Bu problem genellikle Windows güncellemesi sonrasında ortaya çıkar. Özellikle sistemde eski VPN istemcileri, eski endpoint security ajanları, anti-cheat yazılımları, eski DLP/EDR modülleri veya imza uyumluluğu zayıf sürücüler varsa sorun daha sık görülebilir.

Karşılaşılabilecek belirtiler şunlardır:

• Windows açılış sırasında mavi ekrana düşer.
• Kullanıcı login olduktan hemen sonra sistem kendini yeniden başlatır.
• lsass.exe veya LSAIso.exe ile ilişkili hatalar görülür.
• Event Viewer üzerinde LSA, WinInit, Device Guard veya Credential Guard kaynaklı loglar oluşur.
• Güvenli Mod dışında sistem stabil şekilde açılamaz.
• Son yüklenen Windows güncellemesi sonrasında VPN, EDR, anti-cheat veya endpoint ajanları çalışırken sistem çöker.
• BSOD ekranında veya dump analizinde STATUS_IMAGE_CHECKSUM_MISMATCH görülebilir.

Burada dikkat edilmesi gereken önemli nokta şudur: Bu hata tek başına her zaman Credential Guard kaynaklıdır demek doğru değildir. Ancak Windows güncellemesi sonrasında LSA/LSASS çökmesi, eski sürücüler ve Credential Guard/VBS logları aynı anda görülüyorsa, Credential Guard ve sanallaştırma tabanlı güvenlik katmanları güçlü bir şüpheli haline gelir.

Credential Guard ve LSA Isolation Nedir?

Windows 11 ile birlikte güvenlik mimarisi daha agresif hale gelmiştir. Credential Guard, kimlik bilgilerini klasik işletim sistemi belleğinden ayırarak sanallaştırılmış güvenli bir ortamda korumayı amaçlar. Bu yapı Virtualization-Based Security, yani VBS üzerine kuruludur.

Credential Guard aktif olduğunda normal LSA süreci, izole edilmiş LSA bileşeni olan LSAIso.exe ile iletişim kurar. Kimlik bilgileri bu izole süreç tarafından korunur ve işletim sisteminin geri kalanından ayrılır. Microsoft, Credential Guard aktifken LSA’nın LSAIso.exe bileşeniyle haberleştiğini ve bu verilerin VBS ile korunduğunu belirtir.

Windows 11 22H2 ve sonrasında uygun lisans, donanım ve yazılım gereksinimlerini karşılayan cihazlarda Credential Guard varsayılan olarak etkin gelebilir. Microsoft dokümantasyonunda Windows 11 22H2 ve üzeri sürümlerde, gereksinimleri karşılayan cihazlarda Credential Guard’ın varsayılan olarak etkinleştirilebildiği belirtilmektedir.

Bu yapı güvenlik açısından oldukça değerlidir. Çünkü NTLM hash’leri, Kerberos TGT bilgileri ve domain kimlik bilgileri gibi hassas verilerin çalınmasını zorlaştırır. Ancak eski veya uyumsuz yazılımlar bu yeni güvenlik modeline uygun değilse sistem kararlılığı bozulabilir.

Kök Neden: Eski veya Uyumsuz Sürücülerin Güvenli Bellek Alanına Müdahalesi

Bu problemde en sık görülen kök nedenlerden biri, sistemde yüklü olan eski veya uyumsuz kernel-level sürücülerdir. Özellikle aşağıdaki yazılım türleri risk oluşturabilir:

• Eski VPN istemcileri
• Eski sanal ağ adaptörleri
• Anti-cheat yazılımları
• Eski EDR/XDR ajanları
• Eski antivirüs veya endpoint security sürücüleri
• DLP ajanları
• Eski smart card veya kimlik doğrulama bileşenleri
• İmza süresi geçmiş veya Windows 11 24H2 ile uyumsuz kernel sürücüleri
• Kurumsal NAC, 802.1X, VPN veya güvenlik ajanları

Credential Guard ve LSA Protection aktif olduğunda, LSA süreci artık eski Windows sürümlerindeki gibi serbest şekilde erişilebilir bir alan değildir. LSA’ya kod enjekte etmeye çalışan, LSA belleğine erişmeye çalışan veya eski kimlik doğrulama mekanizmalarını kullanan bileşenler sistem tarafından engellenebilir. Microsoft, LSA Protection’ın güvenilmeyen LSA kod enjeksiyonunu ve process memory dumping işlemlerini engellemeye yardımcı olduğunu belirtir.

Bu nedenle güncelleme öncesinde çalışan bazı eski yazılımlar, güncelleme sonrasında aynı davranışı sürdürmeye çalıştığında Windows güvenlik mekanizmaları devreye girer. Eğer ilgili sürücü veya DLL beklenen bütünlük kontrolünden geçemezse sistem kendini korumak amacıyla kritik hata üretebilir.

Neden Güncelleme Sonrası Ortaya Çıkar?

Windows güncellemeleri yalnızca arayüz veya özellik güncellemesi değildir. Özellikle büyük toplu güncellemeler aşağıdaki bileşenleri de etkileyebilir:

• Kernel bileşenleri
• LSASS/LSA güvenlik davranışları
• Device Guard politikaları
• VBS yapılandırması
• Hypervisor davranışı
• Sürücü imza doğrulama mekanizmaları
• Memory Integrity / HVCI kontrolleri
• Credential Guard varsayılan etkinleştirme davranışı

Microsoft, Credential Guard gelişmeye devam ettikçe yeni Windows sürümlerinin daha önce çalışan bazı senaryoları etkileyebileceğini ve kurumların güncelleme öncesinde operasyonel senaryoları test etmesini önerir.

Bu nedenle sorun aslında “Windows güncellemesi sistemi bozdu” şeklinde yüzeysel görünse de arka planda çoğu zaman eski bir sürücü, uyumsuz bir güvenlik ajanı veya Credential Guard ile uyumlu olmayan bir kimlik doğrulama bileşeni vardır.

Geçici Çözüm Mantığı

Sistem sürekli mavi ekrana düşüyorsa veya login sonrası yeniden başlıyorsa ilk hedef sistemi ayağa kaldırmaktır. Bunun için Credential Guard ve VBS katmanını geçici olarak devre dışı bırakmak gerekebilir.

Buradaki amaç güvenliği kalıcı olarak kapatmak değildir. Amaç, sistemi açılabilir hale getirmek, hatalı sürücüyü veya yazılımı tespit etmek, güncellemek ya da kaldırmak ve daha sonra güvenlik özelliklerini kontrollü şekilde tekrar etkinleştirmektir.

Güvenli Mod veya WinRE Üzerinden Çözüm

Sistem normal şekilde açılmıyorsa aşağıdaki yöntemlerden biri kullanılabilir:

Yöntem 1: Güvenli Mod ile Açma

Cihaz açılışta birkaç kez başarısız olursa Windows Recovery Environment, yani WinRE ekranına düşebilir. Buradan şu adımlar izlenebilir:

Troubleshoot
Advanced options
Startup Settings
Restart
Safe Mode

Güvenli Mod açıldıktan sonra Komut İstemi veya PowerShell yönetici olarak çalıştırılır.

Yöntem 2: WinRE Komut Satırı

Eğer Güvenli Mod da açılmıyorsa:

Troubleshoot
Advanced options
Command Prompt

üzerinden işlem yapılabilir.

WinRE içindeyken dikkat edilmesi gereken konu şudur: Komut satırında gördüğünüz HKLM her zaman offline Windows kurulumunun registry yapısı olmayabilir. Bu nedenle bazı durumlarda offline registry hive yüklemek gerekebilir. Ancak sistem Güvenli Mod’da açılabiliyorsa aşağıdaki komutlar doğrudan uygulanabilir.

1. Credential Guard Yapılandırmasını Devre Dışı Bırakma

İlk olarak Credential Guard yapılandırmasını kapatmak için LsaCfgFlags değeri 0 yapılır.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f

Kurumsal cihazlarda politika tabanlı yapılandırma da olabilir. Bu nedenle aşağıdaki policy registry değeri de sıfırlanabilir:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v LsaCfgFlags /t REG_DWORD /d 0 /f

Microsoft dokümantasyonunda Credential Guard’ı devre dışı bırakmak için LsaCfgFlags değerinin 0 olarak ayarlanması gerektiği ve bu değerin silinmesinin her zaman yeterli olmayabileceği belirtilir. Değerin açıkça 0 yapılması önerilir.

2. VBS Katmanını Geçici Olarak Kapatma

Credential Guard VBS üzerinde çalıştığı için, sorunun devam ettiği durumlarda Virtualization-Based Security katmanı da geçici olarak kapatılabilir.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

Eğer Memory Integrity / HVCI tarafında da sürücü uyumsuzluğu varsa aşağıdaki değer de kapatılabilir:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

Microsoft, Memory Integrity etkinleştirildikten sonra sistem kararsız hale gelirse Windows RE üzerinden ilgili registry değerinin 0 yapılabileceğini belirtir.

3. Hypervisor Başlatmasını Devre Dışı Bırakma

Bazı durumlarda VBS registry üzerinden kapatılsa bile hypervisor katmanı devrede kalabilir. Bu nedenle geçici kurtarma adımı olarak aşağıdaki komut kullanılabilir:

bcdedit /set hypervisorlaunchtype off

Ardından sistem yeniden başlatılır:

shutdown /r /t 0

Bu işlemden sonra sistem normal şekilde açılıyorsa sorun büyük ihtimalle Credential Guard, VBS, HVCI veya bunlarla çakışan bir kernel-level sürücüyle ilişkilidir.

4. Sistem Açıldıktan Sonra Yapılması Gerekenler

Sistem açıldıktan sonra yalnızca “bilgisayar açıldı” diyerek işlemi tamamlamak doğru değildir. Çünkü Credential Guard ve VBS güvenlik özellikleri kapatılmış olur. Kalıcı çözüm için asıl sorunlu bileşen bulunmalıdır.

Öncelikle aşağıdaki yazılımlar kontrol edilmelidir:

• VPN istemcisi
• Endpoint security ajanı
• Antivirüs/EDR/XDR ajanı
• Anti-cheat yazılımı
• Sanal ağ adaptörü oluşturan uygulamalar
• Eski NAC ajanları
• Eski DLP ajanları
• Smart card middleware yazılımları
• Eski donanım sürücüleri
• Eski Wi-Fi, Bluetooth, chipset ve storage sürücüleri

Özellikle güncellemeden hemen önce veya sonra yüklenmiş yazılımlar incelenmelidir. Programs and Features, Device Manager, Event Viewer, Reliability Monitor ve C:\Windows\Minidump klasörü bu aşamada oldukça değerlidir.

5. Event Viewer Üzerinden Kontrol

Aşağıdaki Event Viewer alanları kontrol edilmelidir:

Windows Logs > System
Windows Logs > Application
Applications and Services Logs > Microsoft > Windows > CodeIntegrity
Applications and Services Logs > Microsoft > Windows > DeviceGuard
Applications and Services Logs > Microsoft > Windows > LSA
Applications and Services Logs > Microsoft > Windows > NTLM > Operational

Özellikle şu ifadeler aranabilir:

LSA
LSAIso
Credential Guard
Device Guard
Code Integrity
driver failed
image checksum
not signed
blocked by Credential Guard

Credential Guard durumunu kontrol etmek için yönetici PowerShell üzerinden şu komut kullanılabilir:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Microsoft’a göre bu komut çıktısında 0 Credential Guard’ın çalışmadığını, 1 ise çalıştığını gösterir.

Ayrıca msinfo32.exe çalıştırılarak System Summary altında Virtualization-based Security ve Credential Guard durumları incelenebilir.

6. Sürücü ve Yazılım Temizliği

Sistem açıldıktan sonra yapılması gereken en önemli işlem, uyumsuz bileşeni güncellemek veya kaldırmaktır.

Aşağıdaki işlemler önerilir:

1. VPN istemcisini en güncel sürüme yükseltin.
2. Endpoint security ajanını üreticinin Windows 11 23H2/24H2 uyumlu sürümüne güncelleyin.
3. Anti-cheat yazılımlarını güncelleyin veya geçici olarak kaldırın.
4. Eski sanal network adapter sürücülerini kaldırın.
5. Device Manager üzerinde sarı ünlemli cihazları kontrol edin.
6. Üretici sitesinden chipset, storage, network ve BIOS/UEFI güncellemelerini yükleyin.
7. Kurumsal ajanların imzalı ve desteklenen sürümlerini kullanın.
8. Windows Update geçmişinde son yüklenen güncellemeleri not alın.
9. Gerekirse problemli güncellemeyi geçici olarak kaldırın.
10. Minidump analizi ile çökmede adı geçen sürücüyü tespit edin.

Özellikle CodeIntegrity loglarında adı geçen .sys dosyaları çok önemlidir. Bu dosya hangi yazılıma aitse, ilk olarak o yazılım güncellenmeli veya kaldırılmalıdır.

7. DISM ve SFC ile Sistem Dosyalarını Kontrol Etme

Hata yalnızca Credential Guard veya sürücü kaynaklı olmayabilir. Sistem dosyası bozulması ihtimaline karşı aşağıdaki komutlar da çalıştırılmalıdır:

sfc /scannow

Ardından:

DISM /Online /Cleanup-Image /RestoreHealth

Bu işlemler sistem dosyalarının bütünlüğünü kontrol eder ve Windows imajındaki bozulmaları onarmaya çalışır.

Disk tarafında sorun olup olmadığını kontrol etmek için:

chkdsk C: /f /r

komutu kullanılabilir. Bu komut yeniden başlatma isteyebilir.

RAM şüphesi varsa Windows Memory Diagnostic veya üretici tabanlı bellek test araçları kullanılmalıdır.

8. Kurumsal Ortamlarda Dikkat Edilmesi Gerekenler

Kurumsal yapılarda bu sorun tekil cihazdan çok daha geniş bir etkiye sahip olabilir. Özellikle toplu Windows 11 23H2/24H2 geçişlerinde aşağıdaki kontroller yapılmalıdır:

• Pilot cihaz grubu oluşturulmalıdır.
• VPN, EDR, DLP, NAC ve anti-cheat benzeri kernel-level yazılımlar önceden test edilmelidir.
• Credential Guard varsayılan etkinleştirme davranışı kontrol edilmelidir.
• GPO ve Intune politikaları gözden geçirilmelidir.
• Eski imzalı sürücüler raporlanmalıdır.
• BIOS/UEFI ve Secure Boot uyumluluğu doğrulanmalıdır.
• Windows update ring yapısı kademeli ilerletilmelidir.
• Sorunlu sürücüler için üretici uyumluluk listeleri kontrol edilmelidir.
• Kritik kullanıcı gruplarında güncelleme öncesi restore point veya image backup alınmalıdır.

Kurumsal ortamlarda Credential Guard’ı tüm cihazlarda kapatmak kolay bir çözüm gibi görünse de güvenlik seviyesini düşürür. Bu nedenle önerilen yaklaşım, uyumsuz yazılımı bulup düzeltmek ve Credential Guard’ı tekrar aktif hale getirmektir.

9. Credential Guard’ı Tekrar Etkinleştirme

Sorunlu sürücü veya yazılım güncellendikten sonra güvenlik özellikleri tekrar açılmalıdır.

Credential Guard’ı registry üzerinden tekrar etkinleştirmek için:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 2 /f
bcdedit /set hypervisorlaunchtype auto
shutdown /r /t 0

Burada LsaCfgFlags için:

0 = Credential Guard disabled
1 = Enabled with UEFI lock
2 = Enabled without UEFI lock

şeklinde düşünülebilir. Kurumsal yapılarda genellikle uzaktan yönetilebilirlik açısından “Enabled without lock” tercih edilebilir. Microsoft da Credential Guard’ın uzaktan kapatılabilir olması isteniyorsa UEFI lock olmadan etkinleştirme seçeneğinin tercih edilmesini belirtir.

10. Örnek Kurtarma Komut Seti

Aşağıdaki komutlar, sistem açılmıyorsa ve Güvenli Mod veya WinRE üzerinden geçici kurtarma yapılacaksa kullanılabilir:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard" /v LsaCfgFlags /t REG_DWORD /d 0 /f

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

bcdedit /set hypervisorlaunchtype off

shutdown /r /t 0

Bu komutlar kalıcı güvenlik politikası olarak değil, kurtarma ve analiz amacıyla kullanılmalıdır. Sistem açıldıktan sonra asıl problemli sürücü veya yazılım tespit edilmelidir.

11. WinRE İçinde Offline Registry Kullanımı

Bazı sistemlerde WinRE içinden doğrudan HKLM\SYSTEM üzerinde işlem yapmak beklenen sonucu vermeyebilir. Bu durumda offline Windows registry hive yüklenebilir.

Örnek olarak Windows kurulumu C:\Windows üzerinde ise:

reg load HKLM\OfflineSystem C:\Windows\System32\Config\SYSTEM

Ardından ilgili değerler offline hive üzerinde düzenlenebilir:

reg add "HKLM\OfflineSystem\ControlSet001\Control\Lsa" /v LsaCfgFlags /t REG_DWORD /d 0 /f

reg add "HKLM\OfflineSystem\ControlSet001\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f

reg add "HKLM\OfflineSystem\ControlSet001\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

İşlem bittikten sonra hive unload edilmelidir:

reg unload HKLM\OfflineSystem

Not: WinRE içinde Windows sürücüsü her zaman C: olmayabilir. diskpart, list volume veya dir C:\Windows gibi komutlarla doğru sürücü harfi kontrol edilmelidir.

Windows 11 güncellemesi sonrasında görülen STATUS_IMAGE_CHECKSUM_MISMATCH, LSASS çökmesi veya açılışta mavi ekran problemleri çoğu zaman sistemin kritik bir sürücü, DLL veya güvenlik bileşeniyle ilgili bütünlük problemi algılamasıyla ilişkilidir. Credential Guard, LSA Isolation, VBS ve HVCI gibi güvenlik mekanizmaları Windows 11 ile birlikte daha etkin hale geldiği için eski veya uyumsuz kernel-level yazılımlar bu süreci tetikleyebilir.

Geçici çözüm olarak Credential Guard ve VBS devre dışı bırakılarak sistem ayağa kaldırılabilir. Ancak bu işlem güvenlik seviyesini düşürdüğü için kalıcı çözüm olarak görülmemelidir. Doğru yaklaşım; problemli VPN, EDR, anti-cheat, endpoint ajanı veya sürücüyü tespit etmek, üretici tarafından desteklenen güncel sürümü yüklemek ve ardından Credential Guard/VBS güvenlik özelliklerini kontrollü şekilde tekrar etkinleştirmektir.

Özetle, bu hata yalnızca bir Windows güncelleme problemi değildir. Çoğu zaman güncelleme sonrası sıkılaşan güvenlik kontrollerinin, sistemdeki eski veya uyumsuz sürücülerle çakışması sonucu ortaya çıkar. Bu nedenle çözüm süreci hem kurtarma adımlarını hem de kök neden analizini birlikte içermelidir.