RSS

KB5122882 0x8007000D Hatası: Windows Server 2022 Kesin Çözümü

Eylül 12

Windows Server 2022 üzerinde KB5122882 toplu güncellemesini kurmaya çalışırken sürekli 0x8007000D hatasıyla karşılaştım. Microsoft bu kodu “The data is invalid / Veriler geçersiz” olarak tanımlıyor; ancak bu vaka klasik Windows Update önbelleği bozulmasından daha derin çıktı.

Windows Update bileşenlerini sıfırlamak, DISM ve SFC çalıştırmak, güncellemeyi Microsoft Update Catalog üzerinden indirip çevrimdışı kurmak sorunu çözmedi. Kesin teşhis ancak CBS.log içindeki delta hydration hataları incelendiğinde kondu.

Bu yazıda sorunun başından sonuna kadar uyguladığım adımları, işe yaramayan standart yöntemleri ve güncellemeyi başarıyla kurduran çözümü derledim.

Ortam ve belirti

  • İşletim sistemi: Windows Server 2022 Standard, 21H2
  • Başlangıç derlemesi: 20348.2461
  • Hedef güncelleme: KB5122882
  • Hedef derleme: 20348.5622
  • Hata kodu: 0x8007000D / Error 13

Windows Update kurulumu belirli bir noktaya kadar ilerliyor, ardından “Veriler geçersiz” hatasıyla geri dönüyordu. Yeniden başlatma bekleyen bir işlem yoktu ve ilk sağlık kontrollerinde component store bozulması görünmüyordu.

İlk uygulanan standart onarımlar

İlk şüphe Windows Update önbelleğiydi. İlgili servisleri durdurup SoftwareDistribution ve catroot2 klasörlerini yeniden oluşturdum:

net stop wuauserv
net stop bits
net stop cryptsvc

ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

net start cryptsvc
net start bits
net start wuauserv

Ardından sunucuyu yeniden başlatıp sistem dosyalarını denetledim:

DISM /Online /Cleanup-Image /ScanHealth
sfc /scannow

İlk SFC turu bazı dosyaları düzeltti. İkinci tur temiz tamamlandı. Buna rağmen KB5122882, Windows Update üzerinden yeniden denendiğinde yine 0x8007000D ile başarısız oldu.

Çevrimdışı MSU kurulumu da başarısız oldu

Bir sonraki adım Microsoft Update Catalog’dan resmi MSU paketini indirip Windows Update istemcisini devreden çıkarmaktı:

wusa.exe C:\Temp\KB5122882.msu /quiet /norestart

Aynı hata devam edince MSU paketini açıp doğrudan DISM ile eklemeyi denedim:

DISM /Online /Add-Package /PackagePath:C:\Temp\KB5122882 /NoRestart

Bu deneme de yüzde 100’e kadar ilerleyip 0x8007000D ile sonuçlandı. Böylece problemin Windows Update önbelleğinden veya yalnızca WUSA katmanından kaynaklanmadığı kesinleşti.

Asıl ipucu CBS.log içindeydi

Windows dizinindeki Logs/CBS/CBS.log dosyasındaki son hataları süzdüğümde aşağıdaki yapıda kayıtlar gördüm:

Hydration failed for component ...
on file ... with NTSTATUS -1073283059
Matching Component = ...
FileHasForwardReverseDeltas = false
GenerateReverseDelta = true

Hatalar tek bir dosyaya bağlı değildi. Lisanslama, kullanıcı arabirimi, ses, kimlik doğrulama ve Terminal Services bileşenlerinde hem amd64 hem de wow64 dosyaları etkileniyordu. Örnekler arasında şunlar vardı:

  • DefaultPpd-csvlk-pack-ppdlic.xrm-ms
  • twinui.appcore.dll.mun
  • sppcomapi.dll ve sppcomapi.dll.mun
  • LicensingUI.exe ve slui.exe
  • SpeechUX.dll, SpeechUXWiz.exe ve SPTIP.DLL
  • eappgnui.dll ve dsdmo.dll
  • rdvvmtransport.dll

Kök neden: delta hydration zinciri

Windows toplu güncelleme paketleri her dosyanın tamamını taşımak yerine bazı bileşenlerde ileri ve geri delta dosyaları kullanabiliyor. CBS, mevcut dosyadan hedef sürümü üretmeye çalışırken bu delta zincirini kuramadığı için paketi “veri geçersiz” hatasıyla durduruyordu.

İlginç olan şuydu: mevcut tam dosyanın hash değeri doğruydu. Sorun doğrudan hedef ileri deltasını mevcut dosyaya uygulama aşamasındaydı. Çalışan zincir şu oldu:

  1. Kurulu tam dosyaya, kurulu bileşenin r klasöründeki geri delta uygulandı.
  2. Böylece güncellemenin beklediği temel sürüm yeniden üretildi.
  3. Bu temel sürüme KB5122882 paketindeki f ileri deltası uygulandı.
  4. Üretilen hedef dosyanın SHA-256 değeri, resmi Microsoft manifestindeki DigestValue ile karşılaştırıldı.
  5. Yalnızca hash birebir eşleştiğinde tam dosya açılmış pakete yazıldı ve ilgili ileri delta kaldırıldı.

Delta işlemleri Windows’un kendi msdelta.dll kitaplığındaki ApplyDeltaB fonksiyonuyla yapıldı. Bu aşamada hash kontrolü kritik: üretilen dosya resmi manifestteki değerle eşleşmiyorsa kuruluma devam edilmemeli.

Neden işlem birkaç tur sürdü?

CBS ilk karşılaştığı bozuk delta grubunda kurulumu durduruyordu. İlk bileşenler onarıldıktan sonra paket yeniden çalıştırıldığında bir sonraki grup görünür hale geldi. Bu nedenle akış birkaç kez tekrarlandı:

DISM ile kurmayı dene
→ CBS.log içindeki yeni hydration hatalarını bul
→ İlgili hedef dosyaları üret ve hash doğrula
→ Paketi yeniden kur

Son turda amd64 bileşenler geçildi, ardından aynı dosyaların wow64 karşılıkları ortaya çıktı. Onlar da aynı yöntemle üretildikten sonra paket, önceki hata noktasını geçti ve kurulumu tamamladı.

Başarılı kurulum

Düzeltilmiş ve manifest hashleri doğrulanmış açılmış paket şu komutla tekrar kuruldu:

DISM /Online /Add-Package /PackagePath:C:\Temp\KB5122882-expanded /NoRestart

Bu kez sonuç:

The operation completed successfully.
EXIT=3010

3010, kurulumun başarılı olduğunu ve tamamlanması için yeniden başlatma gerektiğini ifade ediyor. Sunucu yeniden başlatıldı ve Windows giriş ekranına ulaştıktan sonra guest agent üzerinden kontroller yapıldı.

Kurulum sonrası doğrulamalar

Yalnızca “kurulum başarılı” mesajıyla yetinmedim. Paket, derleme, component store ve servisleri ayrı ayrı doğruladım:

Get-HotFix -Id KB5122882

DISM /Online /Get-PackageInfo  /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~20348.5622.1.23

DISM /Online /Cleanup-Image /CheckHealth
sfc /scannow

İlk reboot sonrasında sonuçlar şöyleydi:

  • Windows derlemesi 20348.5622 oldu.
  • Get-HotFix, KB5122882’yi gösterdi.
  • Paket durumu Installed olarak doğrulandı.
  • CBS ve Windows Update reboot bayrakları temizdi.
  • SSH, Terminal Services, IIS ve QEMU Guest Agent servisleri çalışıyordu.

Ancak ilk CheckHealth sonucu component store’u “repairable” olarak işaretledi. Bu nedenle işi burada bırakmadım:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
DISM /Online /Cleanup-Image /CheckHealth

RestoreHealth başarıyla tamamlandı. Son SFC taraması “Windows Resource Protection did not find any integrity violations” sonucunu verdi. Nihai CheckHealth çıktısı ise:

No component store corruption detected.
The operation completed successfully.

Sonuç

Bu vakada 0x8007000D, ne basit bir Windows Update önbelleği problemi ne de klasik component store bozulmasıydı. Sorun, kurulu bileşenlerle KB5122882 paketindeki ileri deltalar arasındaki hydration zincirinin kurulamamasıydı.

Kesin çözüm; CBS logundan hatalı bileşenleri tespit etmek, kurulu sürümün geri deltasından beklenen temeli üretmek, hedef ileri deltasını bu temele uygulamak ve ortaya çıkan her dosyayı resmi manifest hashine göre doğrulamaktı.

Önemli not: Bu yöntem ileri seviye bir servicing müdahalesidir. Yalnızca Microsoft’tan indirilen resmi ve imzası geçerli paketlerle çalışılmalı, her üretilen dosya manifest hashine göre doğrulanmalı ve işlem öncesinde geri dönüş planı hazırlanmalıdır. Hash doğrulaması olmadan component store içine dosya taşınmamalıdır.

 

Posted by on 12 Eylül 2026 in Bilgisayar, Server

Leave a comment

Tags: , , , , ,

Kaligrafi Çalışma Kağıdı İndir

Aralık 04

İstediğiniz ölçülerde Kaligrafi çalışma kağıdı indirmek için bu siteyi kullanabilirsiniz. Kağıt boyutu, uç kalınlığı, yazı eğimi açısı vb. seçenekler ile kaligrafi çalışma kağıdı indirmek için özel bir site:

Siteye gitmek için resme tıklayın.

 

Posted by on 04 Aralık 2018 in Bilgisayar

Leave a comment

PHP CLI define configuration directive

Ocak 25

Komut satırından (CLI: Command Line Interface) PHP scripti çalıştırırken, scriptin sağlıklı çalışması için daha yüksek memory limit ihtiyacınız olabilir. Bunu “-d” yada “-define” parametresini komutta kullanarak yapabilirsiniz.
Bu seçeneği kullanarak diğer php.ini’deki ayarları sadece bu komutla çalıştırdığınızda geçerli olmak üzere değişiklik de yapabilirsiniz. Örnek olarak memory_limit değişkenini şöyle değiştiriyoruz:
php -d memory_limit=128M script.php
Bu seçenek size sadece php.ini içinde izin verilen herhangi bir konfigürasyon seçeneğini ayarlamanıza olanak verir.

Php Manual’da -d foo[=bar] Define INI entry foo with value 'bar' şeklinde açıklanıyor.

 

Posted by on 25 Ocak 2016 in Bilgisayar, Programlama

Leave a comment

ssh key oluşturma ve izin verme

Mayıs 30

How To Set Up SSH Keys

About SSH Keys

SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.

Step One—Create the RSA Key Pair

The first step is to create the key pair on the client machine (there is a good chance that this will just be your computer):

ssh-keygen -t rsa

Step Two—Store the Keys and Passphrase

Once you have entered the Gen Key command, you will get a few more questions:

Enter file in which to save the key (/home/demo/.ssh/id_rsa):

You can press enter here, saving the file to the user home (in this case, my example user is called demo).

Enter passphrase (empty for no passphrase):

It’s up to you whether you want to use a passphrase. Entering a passphrase does have its benefits: the security of a key, no matter how encrypted, still depends on the fact that it is not visible to anyone else. Should a passphrase-protected private key fall into an unauthorized users possession, they will be unable to log in to its associated accounts until they figure out the passphrase, buying the hacked user some extra time. The only downside, of course, to having a passphrase, is then having to type it in each time you use the Key Pair.

The entire key generation process looks like this:

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/demo/.ssh/id_rsa.
Your public key has been saved in /home/demo/.ssh/id_rsa.pub.
The key fingerprint is:
4a:dd:0a:c6:35:4e:3f:ed:27:38:8c:74:44:4d:93:67 demo@a
The key's randomart image is:
+--[ RSA 2048]----+
|          .oo.   |
|         .  o.E  |
|        + .  o   |
|     . = = .     |
|      = S = .    |
|     o + = +     |
|      . o + o .  |
|           . o   |
|                 |
+-----------------+

The public key is now located in /home/demo/.ssh/id_rsa.pub
The private key (identification) is now located in /home/demo/.ssh/id_rsa

Step Three—Copy the Public Key

Once the key pair is generated, it’s time to place the public key on the virtual server that we want to use.

You can copy the public key into the new machine’s authorized_keys file with the ssh-copy-id command. Make sure to replace the example username and IP address below.

ssh-copy-id user@123.45.56.78

Alternatively, you can paste in the keys using SSH:

cat ~/.ssh/id_rsa.pub | ssh user@123.45.56.78 "mkdir -p ~/.ssh && cat >>  ~/.ssh/authorized_keys"

No matter which command you chose, you should see something like:

The authenticity of host '12.34.56.78 (12.34.56.78)' can't be established.
RSA key fingerprint is b1:2d:33:67:ce:35:4d:5f:f3:a8:cd:c0:c4:48:86:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '12.34.56.78' (RSA) to the list of known hosts.
user@12.34.56.78's password: 
Now try logging into the machine, with "ssh 'user@12.34.56.78'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Now you can go ahead and log into user@12.34.56.78 and you will not be prompted for a password. However, if you set a passphrase, you will be asked to enter the passphrase at that time (and whenever else you log in in the future).

Optional Step Four—Disable the Password for Root Login

Once you have copied your SSH keys unto your server and ensured that you can log in with the SSH keys alone, you can go ahead and restrict the root login to only be permitted via SSH keys.

In order to do this, open up the SSH config file:

sudo nano /etc/ssh/sshd_config

Within that file, find the line that includes PermitRootLogin and modify it to ensure that users can only connect with their SSH key:

PermitRootLogin without-password

Put the changes into effect:

reload ssh

Digital Ocean Addendum

The Digital Ocean control allows you to add public keys to your new droplets when they’re created. You can generate the SSH Key in a convenient location, such as the computer, and then upload the public key to the SSH key section.

Then, when you create a new VPS, you can choose to include that public key on the server. No root password will be emailed to you and you can log in to your new virtual private server from your chosen client. If you created a passphrase, you will be prompted to enter that upon login.

 

Posted by on 30 Mayıs 2015 in Linux

Leave a comment

Üst Menüye Tıklamayı Engelleme

Şubat 15 
var $j = jQuery.noConflict();
$j(document).ready(function () {
    $j("li:has(ul)").children("a").click(function () {
        return false;
    });
});
 

Posted by on 15 Şubat 2015 in Web

Leave a comment
← Older posts