A couple of days ago, I suddenly got file corruption errors trying to push to a git repository. After longs days of debugging I found out that my git installation seems to sometimes produce broken blobs of binary files. So if I create a new git repository, put in a file, and just hash it:

git hash-object -w .\NS_KrampusAttack.uasset

I get the following error by git fsck:

git fsck
Checking ref database: 100% (1/1), done.
error: inflate: data stream error (incorrect data check)
error: corrupt loose object 'f666989a79a47ed8d6575b8d2add3892b62d6c84'
error: unable to unpack contents of .git/objects/f6/66989a79a47ed8d6575b8d2add3892b62d6c84
error: f666989a79a47ed8d6575b8d2add3892b62d6c84: object corrupt or missing: .git/objects/f6/66989a79a47ed8d6575b8d2add3892b62d6c84
Checking object directories: 100% (256/256), done.
notice: HEAD points to an unborn branch (master)
notice: No default references

In this case NS_KrampusAttack.uasset is a binary file from my Unreal Engine repository where I first noticed the problem. The wrong blob creation occurs randomly/nondeterministic though: Not every time I run hash-object on the same file it is incorrect, rather it goes wrong with around 10% probability, but I saw the problem with a lot of different binary files. The file in question actually sits untouched without flaw in my git repository since April 2024.

Of course I first tried deleting and reinstalling git, and also downloaded git portable/thumbdrive edition, without it making any difference. I am not aware of dependencies I could try to reinstall.

Here are some other things I tried and found out:

• Does not seem to occur with regular sources files
• The resulting broken files look very similar, but are not bitwise identical
• I do not believe it is a physical hard drive problem. I tried chkdsk and found no errors. The problem also occurs on my other internal drive in the same laptop
• A different computer can create the git blobs without problem. If copied over they also work on the laptop with the problem
• To deactivate Windows Defender real time protection didn't fix the problem either
• I use git lfs, but not for the files in question
• I vaguely remember that githubs gave me some .net errors when I tried to push. Unfortunately I didn't save any of them, since back then I thought the problem was something different
• I haven't noticed any other problems on my laptop so far
• I pasted lots of stuff into ChatGPT, and it is strongly convinced that the problem is in zlib. I am not sure why, it never gave me a good reason though, and was just repeating the same stuff over and over (thanks dear AI overlord)
• The problem does not seem to occur when I set git config core.compression 0. But this does not feel like a solution, since there must be something broken on a more fundamental level
• Unpacking a corrupted file with python3 and zlib wasn't possible either, so the problem must be with writing and not with reading.

This is the git I version I use:

git version --build-options
git version 2.51.0.windows.2
cpu: x86_64
built from commit: ade1f1c136682d1bed178d573dc4dc40dca11623
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.16.0
OpenSSL: OpenSSL 3.5.3 16 Sep 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1

My Windows version is Version 24H2.

Hope you can help me with that problem. I cannot simply just reinstall windows.

Thanks in Advance :)

Edit of 13 October: Some other things I found out/tried:

• The varying core.compression levels change the probability of a corrupt object being created, but the chance is actually never zero
• Contrary to what I claimed yesterday, the bug is rare with core.compression 0, but it also happens sometimes
• The bug also happens when correctly created blobs are packed with git gc
• Changing to an older git (git version 2.44.0.windows.1) didn't change anything
• I gave Windows Memory Diagnostics (RAM check) a try and it didn't find any error either
• I tried packaging my game, as well as creating very large .7z files with 7zip, and compressing&decompressing files with varying compression levels with python->zlib, all of which worked without error. Because of this and the drive checks I ran saturday, I am now pretty sure it is not an error of the drive or low level Windows file system per se
• Staying on the same machine, but using wsl (Windows Subsystem for Linux) actually works fine as well! Even in the same repository, accessing it via /mnt/
• I tried System->Recovery->"Fix Problems using Windows Update" in the Win11 settings as well, but that didn't solve the problem either

Since the question got asked in the comments, some information about the corrupt files:

• They start identical with a correctly created object and stop being identical somewhere in the middle
• Two corrupt results of hash-object of the same file are not identical either
• File sizes are extremely similar in any case
• The actual hash is always identical though. NS_Krampus... will always cook into f666980... whether corrupted or not
• Running the command

git cat-file blob f666989a79a47ed8d6575b8d2add3892b62d6c84 prints a lot of stuff (it's a long file) and then ends with:

                    FW'W\.å¢ÈWÍWıWÈ^
FW'W\.å¢ÈWÍWıWÈ^                    X╬╬W
                X╬╬WÆק×Ü®å¢È×Í×ı×ÈÞ
                                    Ø╬╬WFW'W\.å¢ÈWÍWıWÈ^
                                                        X╬╬WFW'W\.û¢ÈWÍWıWÈ^╬╬WFW'W\.û¢ÈWÍWıWÈ^╬╬WFW'W\.û¢ÈWÍWıWÈ^╬╬WFW'W\.û¢ÈWÍWıWÈ^╬╬WFW'W\.û¢ÈWÍWıWÈ^╬╬WFW'W\.å¢ÈWÍWıWÈ^
                                                   X╬╬W FW'W\.Ä¢ÈWÍWıWÈ^X╬╬W"FW'W\.û¢ÈWÍWıWÈ^Xerror: inflate: data stream error (incorrect data check)
fatal: unable to stream f666989a79a47ed8d6575b8d2add3892b62d6c84 to stdout
PS D:\UE\P\TerraOnlyv3> [?61;4;6;7;14;21;22;23;24;28;32;42;52c

The numbers and the [ on the next line are created by git cat-file and not by me. If run on a correct iteration, the last lines look pretty similar, but the obscure letters created from interpreting binary data are a little bit different.