WindowsのZLIB：gzopen/gzwrite/gzcloseは、誤って去勢された出力ファイル/ウイルス対策ソフトウェアを生成しますか？

Question

私は数日間、非常に不思議なバグを追いかけていましたが、これは（ZLIB library）の周りを回っているようです。毎月1回程度、特定の生産環境でのみ発生します。

1. プログラムがファイルXへの書き込みにgzopenを呼び出します。ここでは、コードが何をするかです。
2. プログラムは、ファイルにデータを書き込み、いくつかはgzwriteです。
3. プログラムは最後にファイルをフラッシュするgzcloseを呼び出します。

通常、すべて正常に動作し、ファイルXが有効です。それはCRCとソースストリームの長さで適切に終端されます。

しかし、障害の1つで、Xが壊れていることがわかります。データの先頭は正確ですが、オフセットは0x00302000から始まり、すべてのバイトがnullです。 CRCと長さを符号化する最後の8バイトもゼロです。ただし、ファイルのサイズは正しいです！さらに悪いことに、同じシステムが数分前に非常に似たファイルを正常に圧縮しました。

注：使用しているZLIB.DLLのバージョンは1.1.3です。はい、私は知っている、それはいくつかのセキュリティホールが含まれていると私たちは最新のZLIB 1.2.3にアップグレードする必要がありますが、私はゼロ設定の原因を見つけるまで私のセットアップで何も変更したくないです。

私はメモリの破損を排除したと思います（ところで、どのように壊れたメモリヒープは、出力ストリームに0しか書き込まないのでしょうか？それは妥当でしょうか？）、 ZLIBは私のアプリケーションのDLLよりも別のCライブラリにリンクされているので、問題はあるかもしれませんが、ストリームは単純でストリームはシンプルであり、私は見つけることができます。私はシステム内の他の要素しか疑うことができません。

私はCライブラリ（CRTDLL.DLL）、Win32 API、NTFSスタック、I/Oスタック、低レベルのデバイスドライバ、ハードディスクとハードディスクのファームウェアに自信を持っています。 Visual C++ 2008は、少なくともこの場合、正しいバイナリを生成すると信じる傾向があります。

このように、ウイルス対策ソフトウェアが原因である可能性がありますか？少なくともKasperskyはDLLを潜在的な脅威と認識しているので、ZLIBには注意が必要です。しかし、感染が（間違って）発見された場合、単にアンチウィルスがデータの代わりにゼロを書き込むことは政治的に正しいでしょうか？あるいは、これはウイルス対策のバグでしょうか？

または、私は完全にポイントを逃していますか？

Answer 1

他に何も知らずに、私はあなたのコードではなく、ウイルス対策コードを疑うでしょう。

正しい長さのデータをファイルに書き込むが、間違ったバッファを渡すと、ファイル内のデータとして「すべてゼロ」となるという単純なエラーが必要になります。

あなたが持っているように、時々見つけにくい単純なエラーが非常に大きな混乱につながることがあります。

私はこのトラブルシューティングをしていた場合、私はなります

• 問題が停止するまで、簡素化簡素化簡素化します。複雑さを段階的に戻します。
• はあなたのポインタとポインタ演算あなたが適切
• が0xAAをではなく、0x00のように、割り当てられたバッファにマーカーバイトを格納アロケータを使用してファイルを閉じる&をフラッシュしている
• チェックを確認してください。これにより、ファイルに書き込まれているバッファがゼロ（ゼロ）のバッファであるかどうかを確認できます。通常の状況で
• デバッガでそれをすべてを通してステップ

、gzipで圧縮データがゼロのlooong連続を持っていることはありません。これらは、辞書と長さのコードに分解されます。