AVD ve FSLogix Oturum Sonrası Siyah Ekran: Ekim 2026 Düzeltmesi ve Kontroller
AVD ve FSLogix siyah ekranı için 13 Ekim düzeltmelerini; profil günlükleri, pilot geçiş ve eski geçici politikaların değerlendirilmesiyle açıklıyoruz.
AVD ve FSLogix Oturum Sonrası Siyah Ekran: Ekim 2026 Düzeltmesi ve Kontroller
İlk yayın araştırması: 5 Ekim 2026. Son kontrol: 15 Ekim 2026. Microsoft, 27 Ağustos 2026 tarihli KB5120998 ve sonraki güncellemelerden sonra bazı cihazlarda masaüstünün yüklenmemesi sorununu belgeledi. Kayıt özellikle FSLogix kullanan Azure Virtual Desktop ana bilgisayarlarına ve mevcut kullanıcı profillerine dikkat çekiyor. Belirtiler arasında oturum sonrası siyah ekran ve Explorer çökme kayıtları bulunuyor. 15 Ekim güncellemesi: Microsoft artık bu sorunu Resolved olarak listeliyor. 24H2/25H2/26H2 için KB5127648, 26H1 için KB5127646 düzeltmeleri 13 Ekim 2026 tarihinde yayımlandı. [1][4][5]
Bu yazıdaki inceleme sırası bir operasyon önerisidir. Resmî kaydın kapsamı ile aynı görsel belirtiyi veren depolama, profil veya bağlantı sorunlarını ayırmak için hazırlanmıştır.
Önce ekranın hangi aşamada karardığını belirleyin
Kullanıcı “uzak masaüstü çalışmıyor” dediğinde üç farklı durumdan söz ediyor olabilir: bağlantı hiç kurulmuyordur, kimlik doğrulama tamamlanmıyordur veya oturum açılmıştır ama masaüstü gelmiyordur. Bu olayda üçüncü durumun araştırılması önemlidir.
Kullanıcıya hata saatini, bağlantı yaptığı istemciyi ve oturum açma ekranından sonra ne gördüğünü kaydettirin. Fare imleci, görev yöneticisi veya uygulama penceresi görüntülenebiliyorsa bunu da not edin. Görüntü akışının tamamen kopmasıyla masaüstü kabuğunun başlamaması aynı işlem değildir.
Şu sorular kapsamı daraltır:
- Aynı kullanıcı farklı oturum ana bilgisayarında çalışabiliyor mu?
- Aynı ana bilgisayarda başka kullanıcı aynı sorunu yaşıyor mu?
- Yeni bir test hesabıyla masaüstü yükleniyor mu?
- Sorun yalnızca güncelleme almış makinelerde mi görülüyor?
- Masaüstü elle başlatıldığında kullanılabilir hale geliyor mu?
Bu yanıtları ayrı ayrı değişiklik yapmak için değil, sonraki incelemeyi doğru katmana yönlendirmek için kullanın.
Kullanıcıya geçici erişim sağlama
Microsoft'un belirttiği geçici yöntemlerden biri Görev Yöneticisi üzerinden explorer.exe başlatmaktır. Oturum içinde Görev Yöneticisi'ni açın, Yeni görev çalıştır seçeneğini kullanın ve explorer.exe yazın. Masaüstünün gelip gelmediğini kontrol edin. [1]
Bu işlem kullanıcıyı çalışabilir hale getirebilir; kalıcı çözüm olarak değerlendirilmemelidir. Her oturumda tekrarlanması gerekiyorsa hata hâlâ devam ediyor demektir. Explorer başladıktan sonra uygulamaların, dosya erişiminin ve kullanıcı ayarlarının doğru olduğunu da kontrol edin.
Test sırasında mevcut Explorer işlemlerini gelişigüzel sonlandırmayın. Açık dosya işlemleri ve kullanıcı deneyimi etkilenebilir. Görev Yöneticisi erişilemiyorsa yönetici, oturum durumunu kendi yönetim araçları üzerinden incelemelidir.
Profil ve masaüstü kabuğunu birlikte inceleyin
FSLogix günlükleri için Microsoft'un belgelediği ana dizin C:\ProgramData\FSLogix\Logs konumudur. Profil günlükleri bunun altındaki Profile klasöründe yer alır. Olay Görüntüleyicisi'nde FSLogix günlükleri de kontrol edilebilir. İnceleme sırasında kullanıcı adı, oturum zamanı ve işlem kimliğiyle ilgili kayıtları eşleştirin. [2]
Pratik incelemede yalnızca “error” kelimesini aramak yeterli değildir. Profilin yüklenme sırası ve hata oluşmadan önceki işlemler de önemlidir. Aynı zaman aralığında Windows Uygulama günlüğündeki Explorer hatalarıyla profil kayıtlarını yan yana değerlendirin.
Önerilen karşılaştırma tablosu:
- Etkilenen kullanıcı / etkilenen host: Windows derlemesi: Kaydedin; FSLogix sürümü: Kaydedin; Profil yükleniyor mu?: Günlükten doğrulayın; Explorer elle başlayınca sonuç: Kaydedin
- Test kullanıcısı / aynı host: Windows derlemesi: Aynı derleme; FSLogix sürümü: Aynı sürüm; Profil yükleniyor mu?: Günlükten doğrulayın; Explorer elle başlayınca sonuç: Kaydedin
- Etkilenen kullanıcı / karşılaştırma hostu: Windows derlemesi: Kaydedin; FSLogix sürümü: Kaydedin; Profil yükleniyor mu?: Günlükten doğrulayın; Explorer elle başlayınca sonuç: Kaydedin
Mevcut profilin silinmesi ilk adım olmamalıdır. Yeni hesap testi yararlı olabilir ama bu, çalışan kullanıcının profil konteynerini kaldırmayı gerektirmez. Veri kaybına yol açabilecek bir profil işlemi öncesinde yedek ve geri dönüş planı bulunmalıdır.
Kalıcı düzeltme ve eski KIR uygulamalarının değerlendirilmesi
Windows sürümüne uygun 13 Ekim düzeltmesine veya ilgili sorunu çözdüğü doğrulanan daha yeni güncellemeye geçin. 26H1 paketini 24H2/25H2/26H2 paketiyle karıştırmayın. Merkezi imaj, host havuzu ve sonradan kurulan cihazların güncelleme seviyelerini ayrı kontrol edin. [4][5]
KIR, önceki azaltma döneminde belirli bir güvenlik dışı değişikliği geri alabilen mekanizmaydı. Tam güncellemenin kaldırılmasıyla aynı işlem değildir. [3] Artık yeni pilot testin odağı kalıcı düzeltmedir.
Önceden KIR uygulandıysa paketin adı, GPO kapsamı ve etkin ayarı kayıt altına alınmalıdır. Güncelleme sonrası geçici politikanın temizliği için Microsoft'un güncel yönlendirmesini izleyin. Bütün KIR politikalarını topluca silmeyin; başka bir olay için kullanılan politika hâlâ gerekli olabilir.
Kalıcı düzeltme geçici uygulamayı kaldırmadan test edildiyse, sonucu raporda belirtin. Sonra uygun pilotta geçici ayarın geri alınmasından sonraki davranışı da doğrulayın. Böylece çalışmanın hangi koşulda başarılı olduğu belirsiz kalmaz.
Pilot uygulama ve doğrulama planı
Önce küçük bir oturum ana bilgisayarı grubunda uygulayın. Yeni oturum alımını kurumun bakım yöntemine göre durdurun; aktif kullanıcıların işlerini bitirmesini sağlayın. Sürüme uygun düzeltmenin kurulumunu doğruladıktan sonra planlı yeniden başlatma yapın.
Başarı ölçütünü baştan tanımlayın: kullanıcı masaüstü elle müdahale olmadan açılmalı, aynı hesap tekrar giriş yapabilmeli ve ilgili uygulamalar çalışmalıdır. Tek bir başarılı oturum yeterli değildir; farklı kullanıcılar ve daha önce sorun yaşayan mevcut profiller test edilmelidir.
Test grubunda iyileşme varsa diğer ana bilgisayarlara kontrollü biçimde genişletin. Güncelleme seviyesi, politika kapsamı ve yeniden başlatma durumu farklı makinelerde aynı olmayabilir. “GPO oluşturuldu” ile “bütün hostlarda uygulandı” ayrımını raporda koruyun.
Sorun devam ederse
Bu durumda belirtiyi otomatik olarak aynı Windows regresyonuna bağlamayın. Profil depolamasına erişim, kapasite, izinler, oturum kilitleri ve kullanıcıya özel başlangıç bileşenleri için ayrı bir inceleme gerekebilir. Bu alanlar alternatif teşhis başlıklarıdır; bu olay için doğrulanmış kök nedenler olarak sunulmamalıdır.
Destek talebine sürüm bilgilerini, profil ve uygulama günlüklerini, yeniden üretme sırasını ve 13 Ekim düzeltmesi sonrasındaki sonucu ekleyin. Önceden uygulanan KIR politikasının durumu da kayıtta bulunsun. Kalıcı düzeltmeye geçişten sonra geçici politikanın temizliğini Microsoft'un güncel yönlendirmesine göre planlayın.
Kaynaklar
[1] Microsoft Windows 11 24H2 Release Health — siyah ekran kaydı
[2] Microsoft FSLogix günlükleri ve teşhis
[3] Microsoft Group Policy ile KIR dağıtımı
İlgili yazılar