問題タブ [deviceiocontrol]

カスタム カーネル モード ドライバーを Windows 7 (64 ビット) マシンで実行しようとしています。ドライバー サービスは開始されましたが、IO 制御要求はエラーを返します。

DeviceIoControl(hDevice, OPEN_PHYSICAL_MEMORY, NULL, 0, ph, sizeof(HANDLE), cb, NULL)

および #define OPEN_PHYSICAL_MEMORY __CTL_CODE(0x8124, 0x801, 0, FILE_READ_DATA ) を定義します。

getlasterror() はエラー コード 24 を返します。

ERROR_BAD_LENGTH

この機能は 32 ビット OS で完全に動作します。このエラーを解決するのを手伝ってください。

ありがとうございました。

残念ながら、このリンクは閉鎖されましたが、実際の質問があります: Windows でボリュームのサイズを取得する

Windows で WMI を使用して Win32_Volume と c:\ ドライブの Capacity プロパティを介してボリュームの容量を取得すると、次の値が取得されます: 499513290752

しかし、私が使用するとき

私が得る: 499513294848 これは、WMI が報告するものよりも正確に 4096 大きいです。これは、ハード ドライブのすべてのボリュームで同じです。(このハンドルは、「\\?\Volume{93b1858d-033d-4719-a42a-870d8eb3fe0d}\」というファイル名で CreateFile() を呼び出して取得した SafeFileHandle です)。

また、次を使用して c:\ ドライブを照会します

合計 121951487 個のクラスター、クラスターあたり 8 セクター、およびセクターあたり 512 バイトがあることを報告します。これは、WMI と同じ 499513290752 バイトになります。

Win32_DiskPartition を使用すると、容量の DeviceIoControl と同じ値が報告されますが、これは奇妙です (ここでのファイル名は、一例として「\\?\GLOBALROOT\Device\Harddisk0\Partition1」です)。

また、「\\.\PhysicalDrive0」で指定された物理ディスクの Win32_DiskDrive と DeviceIoControl 関数から取得した値を比較すると、大きく異なる数値が得られます。

Win32_DiskDrive: 500105249280

IoControl: 500107862016 (約 2.5 MiB の違いだと思います)

Win32_DiskDrive のサイズは、WMI クラスで報告されている 1 セクターあたりのバイト数 * 合計セクター数 (512 バイト/セクター * 976768065 合計セクター = 500105249280) の計算と一致します。Disk Geometry の値は、500105249280 のディスク サイズもサポートしています。

では、どの値/ソースを信頼する必要がありますか? また、ボリュームに対して常に 4096 バイト異なるのはなぜですか? IOCTL_DISK_GET_LENGTH_INFO はパーティションに対してのみ有効であり、物理ディスクまたはボリュームに対しては有効ではありませんか?

更新: いくつかの詳細情報/説明。物理セクターの読み取りも試みましたが、DiskGeometry と Win32_DiskDrive によって報告されたディスク サイズを超えて読み取ることができます。この場合、IOCTL_DISK_GET_LENGTH_INFO の値は実際には正しく、この関数によって報告されたセクター数まで読み取ることができ、それを超えて読み取ろうとするとエラーが発生します。では、他の関数が実際のセクターの合計数/正しいサイズを報告しないのはなぜでしょうか? 物理ディスクは、一部の機能がアクセスできない特定の領域を隠していますか?

このコードをコンパイルして実行すると、次の結果が得られます。

私は OS のカーネル ランドの初心者です。最近、カーネルランドでプログラムがどのように機能するかについて研究しています。

いくつかの Windows API 呼び出しは、カーネルランドのシステム コールの単なるラッパーであることを知っています。最後に syscall/sysret/sysenter を実行してカーネルランドに入り、カーネルランドのレシーバー (KiFastCallEntry など) がそれを受け取り、それを解析して処理するハンドラーにスローします。

しかし、私が知っているカーネルランドと通信するもう 1 つの方法は、DeviceIoControl() のような IOCTL です。これを使用して、カスタム デバイス ドライバーを通信しました。

私の質問は、syscall と DeviceIoControl() の違いは何ですか? Windowsでカーネルランドと通信するために2つ(またはそれ以上)の方法が利用可能/分割されているのはなぜですか? DeviceIoControl を呼び出さずに一連の syscall を使用して、カスタム デバイス ドライバーと通信することはできますか?

私の質問を読んでくれてありがとう。良い一日を過ごしてください ：）

次のコードを実行すると、メモリ位置への無効なアクセスが発生します

しかし、次のコードは正常に動作します。

特定のフォルダー内のファイルの再解析データを取得しようとしています。これは私のREPARSE_DATA_BUFFER

どこで間違ったのかわかりません。私の最初のコードを修正するのを手伝ってください。

私は、libusb と私たちのケースに対応するネイティブ ドライバー (CESG502、CASIO 製) を介して、シリアル デバイスと USB デバイスと通信できるようにする必要がある通信ライブラリの作成者です。シリアル通信と libusb 通信の両方が管理されています。現在、CESG502 (目的のために作成されたドライバー) の使用を統合したいと考えています。

主な問題は、このドライバーに起因します。シリアル ドライバーと同じ方法でバッファリングを管理するのではなく (より多くのデータを受信した場合、ユーザーが要求するまで保存されます)、受信したデータよりも大きなバッファーを開発者が提供することを期待しています。これはReadFile、実際に受信したいバイト数（シリアル、そうでなければ、決して来ない残りを待つだけ）またはバッファのサイズ（CESG502;これをしないと、ドライバーは ) を返しますERROR_GEN_FAILURE。

ドライバーはプロプライエタリなので、修正できません。ライブラリの設計上、ほとんどの場合、ライブラリが動作するように作られているため、ドライバが CESG502 であるかどうかを特定する必要があります。探しています。だから私はここでそれを使用しようとしました:

残念ながら、ERROR_INVALID_PARAMETERシリアル デバイスでも発生する 0x57 ( ) エラーが継続的に発生します。私はページが言ったことに従っています、私はたくさんのことを試しました（ReturnedBytesへの設定sizeof(CHANGER_PRODUCT_DATA)、初期化ProductData、とにかくデータの読み取り、...）そして私はこのエラーがどこから来たのかを見つけました...

これを解決する方法を知っている場合は、事前に感謝します:)