msvcp140dll丢失怎么办win7（msvcp140d11丢失了怎么办）

大家好，我是讯享网，很高兴认识大家。

 </nav><h4 id="質問">質問</h4>

讯享网

_{2019年6月4日火曜日 1:32}

VS2019のC;;でコンソールアプリを新規作成すると、「Hello world.」を出力する雛形が作成されます。

これを何も変更せずにそのままデバッグ実行すると、「Hello world.」が表示された直後にntdll.dllで一般保護例外が発生します。

環境は、Windows 7 32bit です。

いろいろ試した結果、[ツール]-[オプション]-[デバッグ]にある、「デバッグの停止時に自動的にコンソールを閉じる」にチェックを入れると例外は発生しなくなりました。

このチェックを入れることに特に問題はないので（main関数終了時にsystem(“pause”)を呼び出せばそこでコンソールは閉じずに残るので）不自由はないのですが、このチェックを外しても動くようにするのが本来だと思うので、報告させていただきました。

なお、Windows10 64bit環境でも試してみましたが、こちらではチェックを外しても例外は発生しませんでした。

以上

すべての返信 (65)

_{2019年6月19日水曜日 5:56 ✅回答済み | 2 票}

> どういう手法なのでしょう？

> それと、FreeLibraryする方法はだめでした。

> 一応ダンプは保存したので、WinDBGで見ることは可能です。

> トレンドマイクロDLLの影響にはほぼ間違いなさそうですが、
> それを回避するようなデバッグができるようにVisual Studio側で
> なんとかできないのでしょうかね？

という訳で、私が手伝えるのはここまで。

_{2019年6月10日月曜日 5:53}

どうぞよろしくお願いします。

MSDN/ TechNet Community Support Haruka

～参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、
ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、までお気軽にお問い合わせください。～

_{2019年6月11日火曜日 2:07}

VS2019のアップデートも行いましたが、Windows7 32bitの環境ではチェックを外すと、同じ様に例外が発生するので状況は変わりません。

英語サイトへの投稿はちょっと検討してみます。

_{2019年6月11日火曜日 7:11 | 1 票}

> これを何も変更せずにそのままデバッグ実行すると、
> 「Hello world.」が表示された直後にntdll.dllで一般保護例外が発生します。

_{2019年6月11日火曜日 7:29}

例外はVisual Studioでデバッグ実行したときだけ発生します。デバッグビルドしたEXEをエクスプローラから直接起動すると例外は発生しません。

なので、Visual Studio 2019に原因があると思われます。(Windows10の64bit環境だとこの問題は起きないというのもあります）

ntdll内の何処なのかはちょっと調べてみます。

_{2019年6月11日火曜日 7:40 | 1 票}

> なので、Visual Studio 2019に原因があると思われます。
> (Windows10の64bit環境だとこの問題は起きないというのもあります）

水掛け論になってしまうので、これ以上は言及しませんが、私にはこれだけの情報で「Visual Studio 2019に原因がある」と断言できる根拠が全くわかりませんでした。

ちなみに、VS 側で “Microsoft Symbol Server” からのシンボルファイルの自動ダウンロードを有効にし、その状態でコールスタックを確認すれば、どこで落ちたのか確認できます。

_{2019年6月11日火曜日 9:40}

舌足らず申し訳ありませんでした。

「デバッグ実行ではなく単独で実行したときは例外が発生しない」という情報を最初に書き忘れていて誤解を招いてしまったようです。（デバッガー上で例外が捕捉されるのなら単独実行でも例外が発生するはずなのに、発生しないのでVS2019のデバッガーになにかあるのでは？ということです。）

> ちなみに、VS 側で “Microsoft Symbol Server” からのシンボルファイルの自動ダウンロードを有効にし、その状態でコールスタックを確認すれば、どこで落ちたのか確認できます。

ありがとうございます！試してみます。

_{2019年6月12日水曜日 0:13}

だったら WinDBG 上から実行してみて、現象に差異が出るか確認してみればいいのでは？

_{2019年6月12日水曜日 0:16}

今朝、VS2019の更新が来ていたので更新してみましたが状況は変わりませんでした。(Version 16.1.3)

で、例外が発生したときの呼び出し履歴を見ると以下のようになっていました。

例外の内容は「0x7746F45A (ntdll.dll) で例外がスローされました (consoleTest.exe 内): 0xC0000005: 場所 0x00000000 への書き込み中にアクセス違反が発生しました」です。

使用しているWindows7(32bit)の環境の問題かもしれませんが、デバッグなしでの起動(CTRL;F5)だと例外は出ないので、デバッガが関係しているんだと思われます。

讯享网

_{2019年6月12日水曜日 1:11 | 1 票}

_{2019年6月12日水曜日 5:34}

お手数掛けまして申し訳ありません。

まず、VS2019のデバッガ上での動作ですが先程は画像のアップに失敗してまして、改めてテキストで貼り付けると

=======================================

となっており、「RtlActivateActivationContextUnsafeFast」で発生しています。（このntdllの関数が何をしているのかは寡聞にして知りません。もし良ければ教えてください）

それから、WinDBGで実行してみたのですが、例外は発生しません。（Go Handled Exceptionで実行）

＞VS2019 デバッガの問題ならば、WinDBG 上では発生しないと考えられるので、確認されることをお勧めします。

ということですので、この結果からVS2019側に問題がある疑いが濃いと思われます。

それから、もしご存知なら教えていただきたのですが、Visual Studioの

　　　[ツール]-[オプション]-[デバッグ]にある、「デバッグの停止時に自動的にコンソールを閉じる」

の項目ですが、この機能の実現ってどういうふうに行っているのでしょうか？（おそらくVS2019のデバッガにそう言う機能があるのだと思うのですが。）

最初の投稿で書きましたが、このオプションにチェックを入れれば、VS2019のデバッガ動作での例外は発生しません。

そもそもプログラムは

讯享网

と、どこで例外が発生するの？というコードです。

確かに、Windowsのシステムがおかしい可能性は0ではないと思います。（考えたくはないですが）ウィルスやマルウェアの可能性ももしかするとあるかもしれません。

でも、より可能性の高さから言うと、VS2019のデバッガではないかと思うのです。

_{2019年6月12日水曜日 6:56 | 1 票}

提示されているコールスタックを見る限り、私には外部プロセスから DLL Injection されているような状態に見えます。

以下は、Windows 10 x64 環境で notepad.exe を起動時の LdrLoadDll() コールを、WinDBG でトレースしたものです。

_{2019年6月12日水曜日 7:31}

ありがとうございます！勉強になります。

＞VS デバッガには関数呼び出し時のパラメータ値を表示させる機能があるので、それを使えば確認できます。

とのことですが、これは、「呼び出し履歴」の画面で右クリックして「パラメータ値の表示」にチェックを入れるのですよね？どこに表示されるのでしょうか？それとも操作を間違ってますか？

初歩的な質問で申し訳ありません。

※DLL Injectionとなると怪しいと思われるのはトレンドマイクロのウィルスバスター（コーポレート版）かもしれないです。他のプログラムのデバッグ時にProcess ExplorerでThreadを監視していると、トレンドマイクロのDLLがスレッドに現れてるのをよく見かけるので。そうなのかを確認したいのですが、呼び出し時のパラメータ値の表示の仕方がわかりません。よろしくお願いします。

_{2019年6月12日水曜日 8:05}

_{2019年6月13日木曜日 0:39}

色々教えていただきありがとうございます。

プロセスダンプを取ってWinDBGで解析してみました。

讯享网

スタックトレースにntdll!LdrLoadDllらしきものが見当たりませんが、もしかして、アプリを子プロセスとして起動しているVsDebugConsole.exeのダンプが必要なんでしょうか？

ただ、気になるのは、例外が発生してVSにブレークインした時に、アプリの子プロセスにcmd.exeが無いのですよね。デバッグ無しでの起動ならcmd.exeが子プロセスで起動するのですが。（このときは::system(“pause”)でキー入力待ちにしています）

_{2019年6月13日木曜日 0:43}

VsDebugConsole.exeのダンプも取ってみました。

_{2019年6月13日木曜日 1:10 | 1 票}

_{2019年6月13日木曜日 2:10}

まあ、こんなに頑張らなくても、VSのオプションにチェックを入れて、::system(“pause”)でデバッグすればいいのですけど（^^;）、わけが分からずに対処療法的なやり方はどうも不安感が拭えなくて。

下記が”*kvn”の結果です。これ見ると、ntdll!LdrLoadDllのフレームが壊れているようなワーニングが出てます。むむむ？？？どういうことでしょう？

讯享网

追記：最初コメント頂いたときアカウント名があれだし（笑）、「ん？どう見てもVSの問題じゃないの？」と正直思いました（笑）。でも、せっかくお付き合いしてくださってるんだし頑張ってみるかと。でも、DLL Injectonじゃないのかと言われたときは、「ああ、なるほど。それがあるのか」と思いました。ここは経験の差ですね。ACCESS_VIOLATIONはたまに遭遇するのですが、よくわからない場合が多いので、トライ・アンド・エラー的な対応しかやってなかったので、この際いい機会なのでとちょっと頑張ってます。

_{2019年6月13日木曜日 2:42 | 1 票}

dt ntdll!_UNICODE_STRING 005af694 -r

_{2019年6月13日木曜日 3:46}

でました。

予想通り、トレンドマイクロのウィルスバスター関係のDLLでした。（DLLの詳細を見ると、「Trend Micro User-Mode Hook Event Module」というものらしいです。

推測ですが、VSのデバッガーがコンソールウィンドウを閉じないようにするためにシステムを何かHookするような処理がウィルスバスターのリアルタイム検出の処理がなにかバッティングしてるんでしょうね。（ウィルスバスターがウィルスみたいな行為をしてるようにも見えますが。）

ここまでですね。これ以上はウィルスバスターを外さないとだめなので。（コーポレートエディションなので一時的に無効にしたりできない）。うちのシステム担当に報告してもいいけどそれもまた面倒だし、トレンドマイクロがすぐに対応してくれるとは限らないので。

色々とお付き合いして頂きありがとうございました。また、何かの機会がありましたらよろしくおねがいします。

ではでは。

_{2019年6月14日金曜日 0:27}

讯享网

_{2019年6月14日金曜日 5:16}

> Thread 1 の “ntdll!RtlActivateActivationContextUnsafeFast;0x9c” での STATUS_ACCESS_VIOLATION (0xC0000005) が発生するとき、メインスレッドである Thread 0 の状態が常に同じならば、問題は Visual Studio 側にあるような気がしてきました。

これ、具体的にどうやって何を調べんたらいいんでしょう？（まだ調べることは可能です）

ウィルスバスターで読み込まれるDLLはもう一つあるようで、「tmmon.dll」というDLLで、User Monitor Hookingのエンジンらしいです。（例外発生時にはまだ読み込まれていないみたいですが）

それと、Windows10 x64では起きないって言いましたけど、32bitアプリとしてコンソールアプリを動かしたときは起きないのですが、64bitアプリとしてコンソールアプリを起動したときは発生することがわかりました。でも、エラー内容が違います。

例外の内容は、

で、呼出履歴は、

と、なっており、例外発生はntdll.dllではなくcombase.dllになっていました。

実は、今月末くらいで、会社のデスクトップがWindows10 x64に切り替わる事になっていて、実際の移行には時間がかかりますが、精々来月半ばくらいまでがWindows7 x86で確認できるリミットになると思います。

（Windows7も来年早々にサポート切れになるので）

_{2019年6月14日金曜日 6:13}

> これ、具体的にどうやって何を調べんたらいいんでしょう？（まだ調べることは可能です）

_{2019年6月14日金曜日 6:45}

それぞれ３～４分間をおいて3回取りました。

1回め

讯享网

2回め

3回目

讯享网

どこを比較すればいいのか・・・。実行の度にアドレスが変わるので。

よろしくおねがいします。

_{2019年6月14日金曜日 7:03}

_{2019年6月14日金曜日 7:39}

メインスレッドに切り替えるとソースコードでは「cout << “Hello world!” << endl;」を指していました。アセンブラで見ると

「アドレス010E2885 add esp,8」を指しているので、その直前のcall文で例外が発生しているようです。

コンソールにはHello world!は表示されているので、表示した直後ということなのでしょうね。

追記：

実際にアセンブラ表示でステップ実行してみました。やはりcall文の中の何処かのようです。アセンブラ表示に切り替えてステップ実行で見てみましたが、なかなか難しいですね。（何年ぶりだろうアセンブラでデバッグしたのは・・・）

追追記：

意地になってアセンブラを追いかけてみました。どうも<ostrem>のsentryの中で呼ばれているuncaught_exceptionの中の、__vcrt_FlsGetValueの、_LdrGetProcedureAddressExの中で落ちていました。

ostremaのC;;ライブラリが臭い？

_{2019年6月14日金曜日 8:23}

> 010E2880  call        std::operator<<<std::char_traits<char> > (010E1221h)  

u 010E1221 10

それから、Build 時の Run-time Library を以下の設定に変更したバイナリで、もう一度試してもらえますか？

_{2019年6月14日金曜日 8:38}

uコマンドの結果は「認識されないトークンです」と表示されます。（callのところでブレークして確認）

また、確かに/MDdになっていたので/MTdや/MDにしましたが同じ様に例外が発生します。

追記：

すいません。今日はもう帰宅するので月曜日にやってみます。何かやることがあれば書いておいてください。よろしくお願いします。

_{2019年6月15日土曜日 5:39}

コマンド採取例の前提となるコード

讯享网

比較参考のため、私が (不慣れな) VS デバッガで採取した結果を添付しておきます。

0x012BC0D4 : ConsoleApplication1!imp?coutstd:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;
④
>u 0x012b137a
std::operator<<<std::char_traits<char> >:
012B137A  jmp         std::operator<<<std::char_traits<char> > (012B17E0h)
_sprintf_s:
012B137F  jmp         sprintf_s (012B3470h)
_InitializeSListHead@4:
012B1384  jmp         _InitializeSListHead@4 (012B58FDh)
___scrt_stub_for_is_c_termination_complete:
012B1389  jmp         __scrt_stub_for_is_c_termination_complete (012B5990h)

_{2019年6月17日月曜日 0:03}

おはようございます。

もし、足りないものがあれば言ってください。

讯享网

_{2019年6月17日月曜日 1:16}

。。。。という訳で、以下の内容を確認してもらえますか？

<確認してほしいこと>

どれでもいいので、過去に採取したプロセスダンプを WinDBG で開き、Thread 0 の下記 Frame 06 部分に着目してください。

06 002af714 0f4ca79f 757f0000 0f4c18a0 757f0000 KERNELBASE!GetProcAddress;0x44 (FPO: [Non-Fpo])

で、以下のコマンドを実行し、モジュールの先頭アドレスが “757f0000” の DLL と、”0f4c18a0” にセットされている関数名を確認してください。

kvn
lmi
da 0f4c18a0

_{2019年6月17日月曜日 1:55}

KERNEBASE.DLLのFlsGetValue関数ですね。

_{2019年6月17日月曜日 2:13}

> ということは、Thread 1 は Thread 0 での何らかの処理に起因して生成されていると思うのです。

これをヒントにデバッグオプションの「デバッグの停止時に自動的にコンソールを閉じる」にチェックを入れた場合（例外は起きない）と外した場合（例外が起きる）で、std::coutでブレークインしたときのスレッドを確認してみました。チェックを入れたときは

で、チェックを外したときは、

でした。チェックを入れたときはウィルスバスター関係のDLLが入っていますが、チェックを外したときつまり例外が発生するときは、ntdll.dll!_DbgUiRemoteBreakinというスレッドが動いています。起因となっているのはこの関数じゃないでしょうか？

_{2019年6月17日月曜日 2:52}

bp ntdll!DbgUiRemoteBreakin “.echo \; .echo !!!!! Hit ntdll!DbgUiRemoteBreakin !!!!!; kvn; g”

_{2019年6月17日月曜日 3:57}

ヒットしないです。

デバッグオプションのチェックの有無で、アプリの実行形態が変わっています。以下は、Process Explorerでcoutでブレークしたときの状態です。

チェックなし

チェックあり

このVsDebugConsole.exeの子プロセスとして動くときは例外が出て、devenv.exe直接の子プロセスとしてアプリが動くときは、例外が出ません。たぶん、VsDebugConsole.exeがアプリが終了してもコンソール画面を表示し続けるためのプロセスだと思いますが、これが例外を起こしている可能性が高いのでしょうね。

（となるとVisual Stduio側の問題になりますかね・・・）

_{2019年6月17日月曜日 4:57}

VS デバッガ上で “ntdll.dll” や “kernelbase.dll” といった外部モジュール内の関数に “Breakpoint” を張るのって、どーやればいいんですかね？

関数ブレークポイントで設定できますよ。ntdll!DbgUiRemoteBreakinという指定方法も受け付けます。

_{2019年6月17日月曜日 4:58}

もしかして、TrendMicro のモジュールがデバッグ関連の API を Hook していて、それが ntdll!DbgUiRemoteBreakin コールを阻害しているのかなぁ。。。

以下のコマンドの出力結果をもらえますか？

_{2019年6月17日月曜日 5:25}

これは、WinDBGのコマンドですよね。

讯享网

両方共エラーなしですね。

_{2019年6月17日月曜日 7:22}

> 関数ブレークポイントで設定できますよ。
> ntdll!DbgUiRemoteBreakinという指定方法も受け付けます。

> 両方共エラーなしですね。

_{2019年6月17日月曜日 8:23}

chkimgコマンドですけど、例外発生後にプロセスダンプしたものや、EXEをロードして1ステップ実行後にやってみたりとかやりましたけど、エラーなしでした。

> ウィルスバスターって、監視を除外する例外設定ってできるんですよね？
> コンソールアプリと “VsDebugConsole.exe” を、ウィルスバスター監視下から除外する設定をした場合にどうなるか、試してもらえますか？

ああ、自動検索除外はコーポレート版なのでシステム管理者にお願いしないとできないんですよ。それも絶対パスを指定しなといけないので、プログラム開発者からしたらはっきり言って使えないです。（手動検索の除外設定は各PCで設定できるんですけどね。ただし絶対パス。なので、一時的にアンインストールするしか無いのですが、パスワードでアンインストできないように保護されているし・・・）

英語のフォーラムを少し覗いてみたんですが、VS2017で同じような例外に遭遇してる人がいるみたいです。ただ、デバッグオプションのチェックにまで言及しているものはなくて、全く同じかどうか不明です。また、「対応をしているところです」的な返信もあるんですけど、解決したかどうかが動きがないのでわからない。

Virtual PCでゲストOSにVS2019をインストールして確かめる手はありそうですが、そこまでやるかどうか悩みどころ。

追記：

例外が発生してブレークインした時にProcess Explorerで見ると、VsDebugConsole.exeのThreadにはTmUmEvt.dllとtmmon.dllが動いていますが、コンソールアプリの方のThreadにはこの2つは見当たらないです。

_{2019年6月17日月曜日 9:14}

あんまり意味ないかもしれませんが、一応下記コマンドも実行してみてください。(WinDBG で。)

!chkimg -db kernel32

> 英語のフォーラムを少し覗いてみたんですが、
> VS2017で同じような例外に遭遇してる人がいるみたいです。

採取したダンプを lmi コマンドで確認する限り、TmUmEvt.dll はロードされているようなのですが、以下のコマンドで TmUmEvt.dll の PE Header が読めるか確認してもらえますか？

!dh -a TmUmEvt

_{2019年6月17日月曜日 9:28}

> あんまり意味ないかもしれませんが、一応下記コマンドも実行してみてください。(WinDBG で。)

> !chkimg -db kernel32

エラーなしですね。

cout直前でブレークし、VsDebugConsole.exeに張り付いているトレンドマイクロのDLLをProcess ExplorerでSuspend状態にした後に実行しましたが同じでした。例外発生後も活動してないことは確認済み。（例外が出てるのがコンソールアプリの方なのでそうでしょうね。）

確かにウイルスバスターの無い環境でどうなのかは見てみたいところですよね・・・。

x64のコンソールアプリで落ちている例もUSサイトにありましたね。それも未解決みたいですが。デバッグオプションにチェックを入れたら改善するので、MSもあまりやる気がでないのかも？

_{2019年6月18日火曜日 0:40}

_{2019年6月18日火曜日 2:06}

dhコマンドに i オプションがないと言われたので、f オプションで表示させました。

_{2019年6月18日火曜日 2:53}

> dhコマンドに i オプションがないと言われたので、f オプションで表示させました。

 1C000 [     2FC] address [size] of Import Address Table Directory

”!dh -?” の出力はっどうなってますか？

Dumps headers from an image based at address

Options:

_{2019年6月18日火曜日 3:53}

Dumps headers from an image based at address

Options:

Microsoft ® Windows Debugger Version 6.3.9600.17298 X86

バージョンが古いですか？ちょっと新しいバージョンにアップデートしてみます。

_{2019年6月18日火曜日 5:22}

0:000> !dh -f file_search4
…..
   1C000 [     2FC] address [size] of Import Address Table Directory
…..

以下のコマンドで Import Function のリストを表示できます。

dds file_search4;0x1C000 file_search4;0x1C000;0x2FC

もっとも、”!dh -i” 方が見やすいですけど。

_{2019年6月18日火曜日 5:40}

5年前ですね。Windows Kits 8.1ってやつです。

WinDBG PreviewはWindows10でないと使えない？

とりあえず、ddsコマンドの内容を貼り付けます。

讯享网

_{2019年6月18日火曜日 5:52}

Windows10のパソコンにWinDBG Previewを入れて、Windows7で採取したプロセスダンプとPDBファイルを読み込ませて、dh -iで出力させました。

_{2019年6月18日火曜日 6:08}

何気に以下の関数アドレスが、モジュールのマップ状態を一致していませんねぇ。

讯享网

このダンプで lmi コマンドを実行した際の各関数アドレスは、下記のように表示されてますか？

追記

u 000F7CF0 l10

_{2019年6月18日火曜日 6:11}

“WinDbg Preview” では TTD (Time Travel Debugging) という機能がサポートされているので、アプリ開発でのデバッグでは、VS デバッガより強力かも。

Visual Studioの場合、Time Travel DebuggingはEnterprise限定の機能として提供されていますね。

_{2019年6月18日火曜日 6:52}

lmiの結果です。

TmUmEvtは今までなかったのに出ていますね。なんで？

u 000F7CF0 10は以下のようにRange errorが出ます。

讯享网

_{2019年6月18日火曜日 7:07}

_{2019年6月18日火曜日 7:58}

少なくとも今日の分は全く同じダンプファイルを使ってるんですが。。。

さっきWinDBGのバージョンが古いということで、SDK 8.1のインストールをやり直したせいでしょうか？

モジュールの位置がいくつか変わってますよね。TmUmEvtが出現しているし・・・。

とりあえず再度取り直しました。

000f7cf0のアドレスは VCRUNTIME140!vcrt_LoadLibraryExWのアドレスですよね？

uコマンドですが、WinDBGが古いので、10の引数がいらないのかもと打ち込むと次のように出ました。

讯享网

_{2019年6月18日火曜日 8:58}

デバッガが古いと変な出力をすることがあるから、その影響かも。

下記コマンドもお願いします。

_{2019年6月18日火曜日 9:11}

dh -iは使えないので!dh -fでアドレスとサイズを得てからddsで取りました。

_{2019年6月18日火曜日 9:35}

以下をお願いします。

u 0007e65c l10

_{2019年6月18日火曜日 22:52}

Memory access errorになります。

_{2019年6月18日火曜日 23:12}

WinDBG PreviewはWindows 10 バージョン 14257.0 以降がシステム要件になっていました。Win7では使えないです。

_{2019年6月19日水曜日 0:34}

_{2019年6月19日水曜日 1:21}

とりあえず、Windows10のPCにインストールしたWinDBG Previewにダンプファイルとシンボルを読み込ませて取り直しました。取り直したのは、!dh -i TmUmEvtまでです。

讯享网

u 0007e65c l10の結果は、Preview版でも同じ結果になります。

Windows7に最新版のWinDBGをインストールし直して取り直すのはちょっとお待ち下さい。

追記：

!dh -i file_search4の結果もつけておきます。

_{2019年6月19日水曜日 2:00 | 1 票}

讯享网

_{2019年6月19日水曜日 2:26}

> なるほど、この手があったか！！！
> この方法は全く想定していませんでした。

どういう手法なのでしょう？後学のために教えていただければ幸いです。

それと、FreeLibraryする方法はだめでした。元のソースでは”Hello world!“が表示されていましたが、今回は表示されずに例外発生しているので、whileループの中で落ちているのだと思います。

一応ダンプは保存したので、WinDBGで見ることは可能です。(lmiするとTmUmEvtがしっかりといました）

トレンドマイクロDLLの影響にはほぼ間違いなさそうですが、それを回避するようなデバッグができるようにVisual Studio側でなんとかできないのでしょうかね？そうでないとあのデバッグオプションは環境によっては使えないということになります。

_{2019年6月19日水曜日 6:23 | 1 票}

> (個人的には、そのダンプ欲しいけど。ｗｗｗ)

ああ、よければダンプとPDBファイルを差し上げます。下記リンクにおいておきましたのでご自由に。

クラッシュダンプ

どうも、長々とありがとうございました。また、機会があればよろしくお願いします。

_{2019年8月7日水曜日 23:51 | 1 票}

この度Windows7(32bit)からWindows10(64bit)へPCが入れ替えになったのを期に、入れ替え前にLANを抜いた状態でウィルスバスターを外してやってみました。予想通り例外は発生しませんでした。

msvcp140dll丢失怎么办win7（msvcp140d11丢失了怎么办）

すべての返信 (65)

相关推荐