Windows7において標準ユーザ権限で起動した場合「管理者として実行...」でパスワードを入力しないと正常に動作しない

Question

以前開発したAP(VC6)では、Windows7においてユーザアカウントが標準ユーザ権限で起動した場合「管理者として実行...」でパスワードを入力しないと正常に動作しません。
そこで、標準ユーザ権限でも何ら意識せずに実行できるよう、APを作り直したいのですが、Visual Studioの開発環境をバージョンアップして、リコンパイルすれば対応できるのでしょうか？
以前開発したAPの開発言語はC++のMFCやコンソールAPです。
AP(.exe)の下位に幾つかのオリジナルのDLLを呼び出しています。
もし、対応するにあたり何らかの条件があれば御教示ください。

Answer 1

アプリケーションでは対応できません。

この機能がなんのために用意されているかを考えれば、なぜこのような仕組みになっているかわかると思います。

 

どうしてもこの機能をキャンセルしたければ、ユーザー アカウント制御の設定で通知レベルを最低に引き下げてください。

 

Answer 2

例えばWindows XPで、標準ユーザーで起動した場合はどうなるでしょうか？　きっと何の対策もできずにエラーになると思います。Windows Vista / 7の方がパスワードを聞いてくるだけ親切だと思いませんか？

Answer 3

以下の場合、アプリケーションの設計（や仕様）を見直してください。
そういったことは、標準ユーザー権限では実行できませんので。

Program Files に配置していて、同じフォルダーのファイルを書き込み可能な形でオープンしている。
あるいは、HKEY_LOCAL_MACHINE や HKEY_CLASSES_ROOT 以下のレジストリキーを書き込み可能な形でオープンしている。

 

これらのことをしていないのに発生するのであれば、VC6 付属の MFC の設定値保存や関連づけ設定のコードが影響している可能性があります。
開発環境を変更するだけではたぶん、最終的な解決に至りません。
何が悪いのかをきちんとデバッグ・分析して、どうすればよいのかを調べて、結論を出してください。
（関連づけのコードを削除してインストーラーに組み込むことが必要など）

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 4

ご回答深謝します。
現状のAPはWindowsXPの標準ユーザで起動した場合は正常に動作します。
またVistaにおいても標準ユーザで起動した場合も正常に動作します(「管理者として実行...」せずに)。
また、Windows7でUACを一番下に設定した場合は、通常実行及び「管理者として実行...」で実行しても同一のエラーとなります。
AP－オリジナルDLL－オリジナルsys(.sys：WHQL未取得)でUSBデバイスをアクセスする仕様で、CreateFileでデバイスのOpenしている箇所でエラーとなっているようです。
仕様上APを改良しても回避は難しいということでしょうか？

Answer 5

AP － DLL － デバイスドライバ のどこでエラーになるのでしょうか？ 元質問にはデバイスドライバの話はなくVC6 APの質問だったはずですが。質問前にエラー個所を切り分けておきましょうよ。

Answer 6

早速の御回答深謝致します。
DLLでエラーとなります。DLLからSysは見えていない感じです。
APを「管理者として実行...」すると正常動作するので、AP側で何らか考慮すれば回避できるものと期待したのですが。
UACが原因ならば、何故Vistaのユーザ権限(UAC有効)で起動した場合は動作するのか不思議です。

Answer 7

sysが見えていない、とはどういうことでしょうか。sysは正常動作しているのでしょうか？
# って自問自答すれば、原因個所の切り分けぐらいできると思うんですが。 

追記：
「見えていない」＝「見るためのAPIは正常な値を返すがその中に含まれていない」＝DLL側は正常に動作しているですよね。

Answer 8

DLLは正常動作しています(DLLに埋め込んだエラーコードが返る)。
デバイスはデバイスマネジャーで確認する限り正常に認識していることから、sysも正常に動作しているものと考えます。

Answer 9

CreateFileでエラーが起こっているのであれば、そのエラーの詳細を調べた方が良いと思います。
エラーステータスから何が起こっているかを推測できる可能性があると思いますから。

推測で話をしても始まらないのでとにかく取れる情報は取りに行くべきだと思いますよ。
どうやらDLLもデバイスドライバも自作のようなので調査用のコードを仕込んで動かす事は可能ですよね。
ある程度当たりを付ける所までは推測でも良いと思うのですが、
対策を考えるのであればきちんとした原因を探る必要があると思います。
対策は原因ありきだと思うので、どうすれば良いかではなくて何が原因なのかを探るべきかと思います。

 

---

解決した時は、参考になったレスポンスの所にある［回答としてマーク］ボタンをクリックしてスレッドを締めましょう。

Answer 10

ユーザ権限ログイン環境で通常実行時はCreateFileでINVALID_HANDLE_VALUEが返り、GetLastError()で詳細エラーを確認したところ0xb7が返っているようです。

Answer 11

それでデバイスドライバは正常に動作していると言えるのですか？ CreateFile時、呼び出されたデバイスドライバ側はどうなっているのでしょうか。

Answer 12

sysドライバ内部をWinDbgでトレースしたところ、USBデバイス接続時のPnP処理は正常動作(だからデバイスマネジャー上で正常に認識)。
DLLからCreateFile実行してもIRP_MJ_CREATEで定義したモジュールが呼び出されません。「管理者として実行」した場合はCreateFile実行したタイミングでIRP_MJ_CREATEで定義したモジュールが呼ばれ、以降正常に動作します。

Answer 13

http://msdn.microsoft.com/en-us/library/windows/hardware/ff546543(v=vs.85).aspx

If a driver sets the FILE_DEVICE_SECURE_OPEN characteristic when it calls IoCreateDevice, the I/O manager applies the security descriptor of the device object to any relative opens or trailing-filename opens. For example, if FILE_DEVICE_SECURE_OPEN is set for \Device\foo, and if \Device\foo can only be opened by the administrator, then \Device\foo\abc can also be opened by the administrator. The I/O manager, however, prevents a normal user from opening \Device\foo and \Device\foo\abc.

 

Answer 14

ユーザ権限ログイン環境で通常実行時はCreateFileでINVALID_HANDLE_VALUEが返り、GetLastError()で詳細エラーを確認したところ0xb7が返っているようです。

で？GetLastError() の戻り値、0xb7 は、何を意味しているのでしょうか？また、このスレッドでは、アプリケーション、DLL、デバイス ドライバーの3つのプログラムが出てきていますが、それの、どこで起きているのでしょうか・・・って、DLL？では、なぜ、「DLLからSysは見えていない感じです」という判断をされたのでしょうか。

仕事でされているのだと思いますが、ネット上で質問をする前に、まずは上司に報告して下さい。ここに書いていることと同じ事を上司に報告したなら、上司はここに書いてあることと同じ返答をあなたに返すはずです。つまり、エラーケースの切り分け、エラー発生箇所の特定、エラー原因として考えられること、および判断をした理由、という質問です。最終的に上司が納得した内容を、ここに投稿して下さい。その方がずっと短時間で解決できます。例えば、最初の投稿からgalacoさんの返答まで40分かかっており、それへの応答が15時間後です。対面で話をしたなら4～5分で終わっているはずです。これを言うと多くの人が「上司は技術的なことがわからない」というような返答をされるのですが、間違っています。ここで必要なのは、「第三者が判断できるように話をまとめること」です。上司に求めるのは技術的な指導ではなく、「しなければならないことで、していないことはないか、確認してもらうこと」です。それもしてくれないような上司なら、……不幸でしたね。

APを「管理者として実行...」すると正常動作するので、AP側で何らか考慮すれば回避できるものと期待したのですが。

galacoさんの「この機能がなんのために用意されているかを考えれば、なぜこのような仕組みになっているかわかると思います。」という返答を支持します。

他のユーザーに影響を与える様な変更、システムそのものに影響を与える様な変更を行うことに対して、User Access Control が設けられています。ユーザーが接近することを制限します。この制限は、システム側が用意します。アプリケーションは、変更を行うためにユーザーが接近できる窓口です。Vista 以降の UAC 対策は、そのような行為を行わないようにすること、昇格しなくても実行できるようにすることです。ユーザーの許可なく昇格することではありません。ここを勘違いしていらっしゃるのではないでしょうか。今回のケースでは、USB デバイスへのアクセスに制限がかかっているので、その制限をクリアしないとアプリケーションは USB デバイスにアクセス出来ません。ということは、アプリケーションの問題ではなく、USB デバイス（デバイス ドライバ）の問題を疑います。

---

Jitta＠わんくま同盟

Answer 15

こんにちは、ひよこプログラマー　さん。

MSDN フォーラムのご利用ありがとうございます。オペレーターの山本です。

みなさんから、参考になるアドバイスをいろいろいただいたいるようでしたので、他の方にも情報共有するため勝手ながら私のほうで回答としてマークさせていただきました。
アドバイスくださったみなさん、ありがとうございます。

いただいた情報の中で解決に役立った投稿や、参考になる情報など有効な情報には回答としてマークすることをお願いしています。
今後、同じ問題でこのスレッドを参照される方にも、有効な情報を活用いただけるかと思いますので、ご協力よろしくお願いいたします。

今後とも、MSDN フォーラムをよろしくお願いいたします。

日本マイクロソフト株式会社 フォーラム オペレーター 山本 春海