none
Windows10 Fall Creators Update（1709）適用により、OS側の内部API（SetRenameInformationEx）の挙動が変化した RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票

    弊社製品のフィルタードライバーが動作している環境にWindows10 Fall Creators Update（1709）を適用したところ、Wordなどで行なわれている方法での上書き保存が出来なくなりました。
    1709適用前は弊社製品が動作していても問題なく上書き保存が出来ていたため、1709の適用による影響であると考えております。

    また、ProcessMonitorで上書き保存時の動作を調査したところ、上書き保存の際に実行されるOS側の内部API（SetRenameInformationEx）が「ACCESS DENIED」を返しておりました。
    そこで、質問が3点ございます。

    　１．1709で何が変更されたのか？
    　２．OS側の内部API（SetRenameInformationEx）が「ACCESS DENIED」を返す条件は何か？
    　３．回避策をご教示ください。

    なお、問題が発生している環境の詳細は以下のとおりです。

    [環境]
    　OS：Windows10 Fall Creators Update（1709）適用済み（64bit）

    [状況]
    ・Wordなどで行なわれている上書き保存の流れは、以下のとおりです。
    　1)元ファイル（aaaa.docx）を開く
    　2)変更内容を一時ファイル（~WRDnnnn.docx）に保存する［上書き保存操作開始］
    　3)元ファイルを別名（~WRLnnnn.tmp）にリネームする［aaaa.docx → ~WRLnnnn.tmp］
    　4)一時ファイルを元ファイル名にリネームする［~WRDnnnn.docx → aaaa.docx］

    ・弊社製品では、ファイルシステムへの読み書き時にフィルタードライバーで暗号化・復号処理を行なっております。
    　その際、暗号化されたファイル内容を別のメモリマップトファイルに展開し、アプリにファイルハンドルを渡しています。
    　1)アプリで暗号化済みの元ファイル（aaaa.docx）の読み込み操作を開始
    　2)フィルタドライバが復号先の仮ファイル（aaaa.docx.dec）を開き、元ファイルの内容を復号しメモリマップトファイルに展開する
    　3)アプリに仮ファイルのファイルハンドルを渡す

    ・弊社製品が動作中の上書き保存の流れは以下のとおりです。
    　1)元ファイル（aaaa.docx）を開く
    　2)弊社製品によりアプリは仮ファイル（aaaa.docx.dec）を開いている状態となる
    　3)アプリが変更内容を一時ファイル（~WRDnnnn.docx）の仮ファイル（~WRDnnnn.docx.dec）に保存する
    　4)アプリで上書き保存操作を開始
    　5)元ファイルの仮ファイル（aaaa.docx.dec）を別名（~WRLnnnn.tmp）にリネームする［aaaa.docx.dec → ~WRLnnnn.tmp］
    　6)一時ファイルの仮ファイルを『元ファイル名にリネーム』する［~WRDnnnn.docx.dec → aaaa.docx］
    　※この「6)」のリネーム動作がSetRenameInformationExで実行された際に、「ACCESS DENIED」を返しています。
    　※「5)」のリネーム動作はSetRenameInformationExで実行されておりますが、こちらは「SUCCESS」を返しています。

    OSの内部仕様に関わるため、Microsoftのエンジニアの方にお答えいただければと思います。

    以上、よろしくお願いいたします。

    2018年4月10日 7:24
    |

回答

  • Question
    サインインして投票
    1
    サインインして投票

    今ちょっとだけ調べたら。。。
    ファイル システム フィルタ ドライバ側でのリネーム処理のインターフェイスとなる "IRP_MJ_SET_INFORMATION" を調べたところ、Windows 10 1709 で、リネーム処理に関連する構造体に機能拡張されたとの情報がありました。
    --------------------------------------------------------------
    IRP_MJ_SET_INFORMATION
    https://docs.microsoft.com/ja-jp/windows-hardware/drivers/kernel/irp-mj-set-information

    _FILE_INFORMATION_CLASS Enumeration
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/ne-wdm-_file_information_class

    FileRenameInformationEx
    A FILE_RENAME_INFORMATION structure which contains additional flags.
    This value is available starting with Windows 10, version 1709.

    FileRenameInformationExBypassAccessCheck
    A FILE_RENAME_INFORMATION structure which contains additional flags.
    This value is available starting with Windows 10, version 1709.
    This is a special version of the FileRenameInformation operation
    that is used by kernel-mode drivers only in order to bypass security access checks.
    This operation is only recognized by the IOManager and a file system should never receive it.

    _FILE_RENAME_INFORMATION structure
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/ns-ntifs-_file_rename_information
    --------------------------------------------------------------

    で、この機能拡張部分の詳細に関しては、現状ではマイクロソフトからの公式サポート情報はアナウンスされていないんですよね。。。。
    OSR のフォーラムにも情報ないし。。。
    ただ、この機能拡張はフィルタ ドライバを開発する人間にとっては結構インパクトがあると思うので、有償サポートで問い合わせれば何か教えてくれるかもしれません。
    もしかしたら、マイクロソフト側がドキュメントの更新をさぼっただけの、「Document Bug」って可能性もあるし。
    そもそもフィルタ ドライバを社内開発しているのであれば、そちらの人たちはマイクロソフトの有償サポートを使っているのでは？
    (個人的には、マイクロソフトの有償サポートを使わずにフィルタ ドライバを開発すなんて、不可能だと思っています。)
    もしかしたら、この機能拡張に伴いフィルタ ドライバ側での対応が必要なのかもしれません。
    この問題に関しては、まずは社内でフィルタ ドライバを開発されている人に相談した方がいいと思います。
    2018年4月12日 8:13
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ファイル システム フィルタ ドライバを開発されているとのことなので、まさかそこまでひどい勘違いはされていないと思いツッコミは入れませんでしたが、一応補足しておきます。

    SetRenameInformationEx などという API は存在しません。
    "Process Monitor" で採取したログの "SetRenameInformationFile" オペレーション時のコールスタックを確認すれば一目瞭然ですが、SetRenameInformationFile などというフレームは存在しないはずです。
    つまりこの API の名前は、Process Monitor を開発された Mark Russinovich 大先生が便宜上つけた API 名と考えられます。

    釈迦に説法かもしれませんが。。。。
    ファイル リネーム処理は一般的に MoveFileEx() API 経由で行われます。
    MoveFileEx() API がコールされると kernelbase.dll はこのリクエストを Native API である NtSetInformationFile (ZwSetInformationFile) の "FileRenameInformation" コールに変換して、カーネル モード側の NT カーネルに渡します。
    ----------------------------------
    NtSetInformationFile function
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntsetinformationfile
    ----------------------------------

    そして NT カーネルは NtSetInformationFile( FileRenameInformation ) を、IRP_MJ_SET_INFORMATION の FileRenameInformation リクエストに変換して、ファイル システム デバイス スタックに渡します。
    "Process Monitor" もファイル システム フィルタ ドライバを組み込み File I/O 等を監視していますが、"Process Monitor" で検出される "SetRenameInformationFile" オペレーションは、そのファイル システム フィルタ ドライバが IRP_MJ_SET_INFORMATION - FileRenameInformation リクエストを検出したときにロギングされます。
    つまりこのファイル リネーム処理の IRP イベントを、便宜上 "SetRenameInformationFile" オペレーションと表示させているだけです。

    そもそも。。。。
    ファイル システム フィルタ ドライバを開発しているのであれば、MoveFileEx() 等で ERROR_ACCESS_DENIED が返されるという現象はよく目にするのでは？
    大抵の場合、ファイル リネーム処理で STATUS_ACCESS_DENIED が発生する理由は、「他にそのファイルをオープンしているプロセスが存在するから」です。
    自プロセスがそのファイルを二重にオープンしていたり、あるいは他プロセスがそのファイルをオープンしているのであれば、ファイル リネーム処理が拒否されるのは当然の結果です。
    よくある事象としては、SearchIndexer.exe やセキュリティ ソフト等の監視プロセスが一時的にそのファイルをオープンしている場合です。
    "Process Monitor" を使っているのであれば、その対象ファイルが複数オープンされていないか、すぐに確認できるのでは。。。と思います。
    (もっともファイル システム フィルタ ドライバを開発しているのであれば、そのドライバをプチ改造して調べた方が、今後のデバッグに役立つとは思いますが。)
    2018年4月11日 1:35
    |

すべての返信

  • Question
    サインインして投票
    1
    サインインして投票

    Technet フォーラムは、ユーザー同士が技術的な情報を交換しあうためのコミュニティです。

    質問への回答は、Microsoft と直接の関係を持たない善意の第三者が行っていますので、Microsoft 社員からの回答 (Microsoft の公式回答) を希望するのであれば、有償の法人サポートに問い合わせるのが適切かと思います。

     

    フォーラムのご利用方法（質問の投稿）について

    https://social.technet.microsoft.com/Forums/ja-JP/b2074c04-2e91-414d-8e9e-d634be311e31?forum=announceja

     

    法人向けサポートサービス

    https://www.microsoft.com/ja-jp/services/support.aspx

    2018年4月10日 8:21
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ファイル システム フィルタ ドライバを開発している会社は沢山あるし、提供されているフィルタ ドライバも目茶目茶あります。
    マイクロソフトが把握しているドライバだけでも、↓これだけある。
    ---------------------------
    Allocated Altitudes
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ifs/allocated-altitudes
    ---------------------------

    あなたの主張されている現象が「1709の適用による影響」であるなら、上記サイトで示されているドライバでも同様の問題が起きてもおかしくないと思いますが、その点はどのようにお考えでしょうか？
    またファイル システム フィルタ ドライバを開発されているなら、WinDBG 等のカーネル デバッガで OS 内部の挙動を確認するぐらいのスキルが必要になると思いますが、ntdll.dll への NtSetInformationFile() コールから NTFS 等対応するファイル システム ドライバまでのどこでエラーがセットされたのか、ご自身で確認されなったのでしょうか？
    さらに言えば、問題の起きている環境では、マイクロソフトとあなたの会社以外のフィルタ ドライバは存在しないのでしょうか？
    そういった基本的な切り分けが一切行われていない状態で、「1709の適用による影響」と断定できる根拠はなんでしょうか？
    2018年4月10日 9:56
    |
  • Question
    サインインして投票
    0
    サインインして投票

    そもそも Undocumented な内部 API の挙動については Microsoft ではサポートしないし、またどのような動作変化があるかというような公開情報も（そもそも Undocumented なので）存在するはずがありません。

    こうした API は Windows 内部でのみ利用することを想定している物であり、変更がある場合も互換性が考慮されることはありませんので、「動かなくなった」らそれで終わりです。どうしても利用したいのであれば再度独自に API の挙動を解析して、現行バージョンで動作するようあなたのプログラムを修正しましょう。

    hebikuzure

    2018年4月10日 11:50
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ファイル システム フィルタ ドライバを開発されているとのことなので、まさかそこまでひどい勘違いはされていないと思いツッコミは入れませんでしたが、一応補足しておきます。

    SetRenameInformationEx などという API は存在しません。
    "Process Monitor" で採取したログの "SetRenameInformationFile" オペレーション時のコールスタックを確認すれば一目瞭然ですが、SetRenameInformationFile などというフレームは存在しないはずです。
    つまりこの API の名前は、Process Monitor を開発された Mark Russinovich 大先生が便宜上つけた API 名と考えられます。

    釈迦に説法かもしれませんが。。。。
    ファイル リネーム処理は一般的に MoveFileEx() API 経由で行われます。
    MoveFileEx() API がコールされると kernelbase.dll はこのリクエストを Native API である NtSetInformationFile (ZwSetInformationFile) の "FileRenameInformation" コールに変換して、カーネル モード側の NT カーネルに渡します。
    ----------------------------------
    NtSetInformationFile function
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntsetinformationfile
    ----------------------------------

    そして NT カーネルは NtSetInformationFile( FileRenameInformation ) を、IRP_MJ_SET_INFORMATION の FileRenameInformation リクエストに変換して、ファイル システム デバイス スタックに渡します。
    "Process Monitor" もファイル システム フィルタ ドライバを組み込み File I/O 等を監視していますが、"Process Monitor" で検出される "SetRenameInformationFile" オペレーションは、そのファイル システム フィルタ ドライバが IRP_MJ_SET_INFORMATION - FileRenameInformation リクエストを検出したときにロギングされます。
    つまりこのファイル リネーム処理の IRP イベントを、便宜上 "SetRenameInformationFile" オペレーションと表示させているだけです。

    そもそも。。。。
    ファイル システム フィルタ ドライバを開発しているのであれば、MoveFileEx() 等で ERROR_ACCESS_DENIED が返されるという現象はよく目にするのでは？
    大抵の場合、ファイル リネーム処理で STATUS_ACCESS_DENIED が発生する理由は、「他にそのファイルをオープンしているプロセスが存在するから」です。
    自プロセスがそのファイルを二重にオープンしていたり、あるいは他プロセスがそのファイルをオープンしているのであれば、ファイル リネーム処理が拒否されるのは当然の結果です。
    よくある事象としては、SearchIndexer.exe やセキュリティ ソフト等の監視プロセスが一時的にそのファイルをオープンしている場合です。
    "Process Monitor" を使っているのであれば、その対象ファイルが複数オープンされていないか、すぐに確認できるのでは。。。と思います。
    (もっともファイル システム フィルタ ドライバを開発しているのであれば、そのドライバをプチ改造して調べた方が、今後のデバッグに役立つとは思いますが。)
    2018年4月11日 1:35
    |
  • Question
    サインインして投票
    0
    サインインして投票
    [Lapivy]さん

    フォーラムの利用方法および法人向けサポートサービスについてご案内いただきありがとうございます。
    こちらへ問い合わせたのは、Microsoft技術サポートの方から「（フォーラムには）Microsoftのエンジニアも参加しており、回答されることがあります」とご紹介いただいたためです。
    フォーラムでいただいた内容や、当方の調査で困難という判断となれば、有償の法人サポートへ改めてインプットしたく存じます。
    ありがとうございました。
    2018年4月12日 5:27
    |
  • Question
    サインインして投票
    0
    サインインして投票
    [hebikuzure]さん

    ご指摘いただきありがとうございます。

    Undocumentedであることを確認できなかったため、もし公開されているドキュメントがあれば、変更内容について文書化されているものと考え問い合わせた次第です。
    また、文書のあるなしに関わらず、弊社製品側を修正するものとは考えておりますので、動作させることを諦めない間は、おっしゃられているように挙動の調査と修正を行ないたいと思います。
    2018年4月12日 5:27
    |
  • Question
    サインインして投票
    0
    サインインして投票
    [お馬鹿]さん

    丁寧にご返答いただきありがとうございます。

    「1709の適用による影響」と記載したのは、事象が発生する前に変更した内容が「1709の適用」のみであったためです。
    フィルタードライバーが多くあることは存じておりますが、同様の事象が他で起きているかいないかについては、情報を持ち合わせておりません。（ドライバーでの処理内容も多様であるため、どちらも否定するものではございません）

    また、弊社ドライバー内での処理状況の詳細調査および原因箇所の特定を行なう前にこちらのフォーラムへ投稿したことについては、軽率であったと反省しております。
    加えて開発に携わっておらず、ドライバーの開発についても浅学であるため、的外れかつ不適切な用語で混乱させてしまったことをお詫びいたします。

    ご指導いただいた内容については、参考とさせていただき、学びながら調査を進めたいと思います。
    大変ありがとうございました。

    また、こちらのフォーラムでご縁があることもあると思いますので、また懲りずにご指導いただければ幸いでございます。
    2018年4月12日 5:27
    |
  • Question
    サインインして投票
    1
    サインインして投票

    今ちょっとだけ調べたら。。。
    ファイル システム フィルタ ドライバ側でのリネーム処理のインターフェイスとなる "IRP_MJ_SET_INFORMATION" を調べたところ、Windows 10 1709 で、リネーム処理に関連する構造体に機能拡張されたとの情報がありました。
    --------------------------------------------------------------
    IRP_MJ_SET_INFORMATION
    https://docs.microsoft.com/ja-jp/windows-hardware/drivers/kernel/irp-mj-set-information

    _FILE_INFORMATION_CLASS Enumeration
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/wdm/ne-wdm-_file_information_class

    FileRenameInformationEx
    A FILE_RENAME_INFORMATION structure which contains additional flags.
    This value is available starting with Windows 10, version 1709.

    FileRenameInformationExBypassAccessCheck
    A FILE_RENAME_INFORMATION structure which contains additional flags.
    This value is available starting with Windows 10, version 1709.
    This is a special version of the FileRenameInformation operation
    that is used by kernel-mode drivers only in order to bypass security access checks.
    This operation is only recognized by the IOManager and a file system should never receive it.

    _FILE_RENAME_INFORMATION structure
    https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/ns-ntifs-_file_rename_information
    --------------------------------------------------------------

    で、この機能拡張部分の詳細に関しては、現状ではマイクロソフトからの公式サポート情報はアナウンスされていないんですよね。。。。
    OSR のフォーラムにも情報ないし。。。
    ただ、この機能拡張はフィルタ ドライバを開発する人間にとっては結構インパクトがあると思うので、有償サポートで問い合わせれば何か教えてくれるかもしれません。
    もしかしたら、マイクロソフト側がドキュメントの更新をさぼっただけの、「Document Bug」って可能性もあるし。
    そもそもフィルタ ドライバを社内開発しているのであれば、そちらの人たちはマイクロソフトの有償サポートを使っているのでは？
    (個人的には、マイクロソフトの有償サポートを使わずにフィルタ ドライバを開発すなんて、不可能だと思っています。)
    もしかしたら、この機能拡張に伴いフィルタ ドライバ側での対応が必要なのかもしれません。
    この問題に関しては、まずは社内でフィルタ ドライバを開発されている人に相談した方がいいと思います。
    2018年4月12日 8:13
    |
  • Question
    サインインして投票
    0
    サインインして投票
    [お馬鹿]さん
    および
    ご返答いただきました皆さま

    ありがとうございました。
    本インプットで発生していた事象につきましては、原因箇所を特定し解消することが出来ました。

    [原因]
    「IRP_MJ_SET_INFORMATION」に対応する事前処理において、「FileRenameInformation」をキャッチして独自処理を行なっていましたが、
    そもそも「FileRenameInformationEx」をキャッチしておりませんでした。
    （そういったことに気付いておらず、お恥ずかしいかぎりです）

    [対処]
    「IRP_MJ_SET_INFORMATION」に対応する事前処理において、独自処理のために「FileRenameInformationEx」もキャッチするように修正。

    また、アドバイスいただいたことで現象の解決に至っただけでなく、調査のために必要な知識・技術をわずかでも吸収できましたことをお礼申し上げます。

    ありがとうございました。
    2018年4月23日 8:40
    |