3

クライアントのマシン上のWindowsVista/ 7で散発的にクラッシュする低レベル（実際の低レベルのように、基本的にすべてのIOCTL呼び出しと列挙APIへのいくつかの呼び出し）があります。残念ながら、クラッシュダンプを取得することはできませんでしたが、ある有用なユーザーは、プログラムをXP互換モードで実行すると問題が解決したと述べました。

アプリケーションは常に完全な管理者権限で起動されるため（管理者認証が必要な別のプログラムから起動されます）、UACの問題ではありません。非推奨のAPIを使用せず、レジストリハックなどに依存していません。ディスクを列挙するための呼び出しを発行し、IOCTLコマンドを使用して、接続されているすべてのデバイスに関するより低レベルの情報を取得しています。

XP互換モードではどうなりますか？Windowsは、Vista / 7でのクラッシュを防ぐために、アプリケーションに何を注入するか、サンドボックス化するのですか？XP互換モードで正常に動作すると言われる前に、ヒープの破損を最初に疑っていました（ただし、複製または問題の追跡を試みて髪の毛を抜いてしまいました）。

XP互換モードで回避できる可能性のある問題を誰かが提案できますか？この問題に対処するために調査する必要がありますか？ありがとう！

編集：

おそらく非常に重要なもう1つのことは、WIN32 APIを介して公開されていない特定の機能を取得するために、ユーザースペースからDDK/カーネル関数を呼び出していることです。

ZwReadFile、ZwCreateFile、ZwWriteFile、RtlInitUnicodeString、ZwQueryVolumeInformationFile、ZwDeviceIoControlFile、ZwSetInformationFile、ZwCloseを使用しています。

私が呼び出しているIOCTLには、IOCTL_DISK_GET_PARTITION_INFO_EX、IOCTL_STORAGE_GET_DEVICE_NUMBER、IOCTL_DISK_GET_LENGTH_INFO、およびIOCTL_DISK_GET_DRIVE_LAYOUT_EXが含まれます。

4

2 に答える 2

1

これは非常に奇妙ですが、FsInformationClassをFileFsVolumeInformationに設定してZwQueryVolumeInformationFileを呼び出していました。

最初に通常割り当てられ、次にに割り当て超過されたFILE_FS_VOLUME_INFORMATIONのバッファーを渡しました(sizeof(FILE_FS_VOLUME_INFORMATION) + sizeof(TCHAR)*FILE_FS_VOLUME_INFORMATION->VolumeLabelLength)。

それから私は電話 をしました、そしていくつかのマシンFILE_FS_VOLUME_INFORMATION->VolumeLabel[FILE_FS_VOLUME_INFORMATION->VolumeLabelLength/2] = _T('\0');でのみこれはメモリの破損をもたらすでしょう。

過剰割り当てのサイズに関係なく（256文字を余分に割り当てようとしても！）、これにより、をFILE_FS_VOLUME_INFORMATIONバッファーとして使用している場合でも、ヒープが確実に破損します。vector<unsigned char>

カーネルは、サイズに関係なく、何らかの形でバッファに何らかの書き込み保護を設定しているため、破損が発生しているようです。最初のVolumeLableLengthバイトを2番目のバッファーにコピーしてから、ポストペンディング_T('\0')で問題を解決しました。Windowsが割り当ててパラメーターとして渡したバッファーを読み取り専用にする方法/理由、またはFILE_FS_VOLUME_INFORMATION構造体（文字配列で終わる必要があります！）の後に格納するかどうかはわかりませんが、バッファー内のデータを変更しないだけです。私はそのトリックをパスしました....それは特定のマシンでのみ（一貫して100％再現可能）発生するため、クレイジーです。

とにかく：問題は解決しました*ふぅ*！

于 2010-02-23T16:14:31.770 に答える
0

低レベルのドライバーは、XPからビスタに多くの変更が加えられています。影響を受けるIOCTLを使用していると思われます。

于 2010-01-30T19:29:28.273 に答える