none
C で開発したアプリケーションの異常終了に関して RRS feed

  • 質問

  • お世話になっております。

    C ( visual c++ 2013 ) で開発したアプリケーションが異常終了したため、
    エラー時のメモリダンプを取得して windbg で analyze を行ってみました。

    結果として、変数の宣言+初期化の箇所で異常終了していたのですが、
    なぜ異常終了になるのか、原因が分かりません。

    何か思い当たるところが無いか、他にどのような調査をしたら良いか、
    ご教示頂けないでしょうか。

    ※ ビルド環境情報は、
      OS :
        windows 10 pro ( x64 )
      IDE、コンパイラ :
         Microsoft Visual Studio Express 2013 for Windows Desktop
             Version 12.0.40629.00 Update 5
         Microsoft .NET Framework
             Version 4.7.03190
         Visual C++ 2013   06157-004-0441005-02899
             Microsoft Visual C++ 2013
    ※ 事象発生環境は、
      OS:
        windows server 2012 datacenter

    以下、windbg で analyze した際の抜粋です。

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

    STACK_COMMAND:  ~0s; .ecxr ; kb

    FOLLOWUP_IP:
    TEST_PROGRAM!%関数名%+c1 [%programpath%\%sourcefilename%.c @ 2559]
    000007f7`d71d5771 c5f857c0        vxorps  xmm0,xmm0,xmm0

    FAULTING_SOURCE_LINE:  %programpath%\%sourcefilename%.c

    FAULTING_SOURCE_FILE:  %programpath%\%sourcefilename%.c

    FAULTING_SOURCE_LINE_NUMBER:  2559

    FAULTING_SOURCE_CODE:  
      2555:     char            user[4096]  = {'\0'};
      2556:     char            comp_flag[] = "NULL";
      2557:     int            status      = SUCCESS;
      2558:     DWORD            exec_sec    = 0;
    > 2559:     double            exec_t      = 0.0;
      2560:     size_t            data_len    = 0L;
      2561:
      2562:
      2563:     testprintf("execute start. \n");


    SYMBOL_STACK_INDEX:  a

    SYMBOL_NAME:  TEST_PROGRAM!%関数名%+c1

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: TEST_PROGRAM

    IMAGE_NAME:  TEST_PROGRAM.exe

    DEBUG_FLR_IMAGE_TIMESTAMP:  5ce50126

    FAILURE_BUCKET_ID:  STATUS_BREAKPOINT_80000003_TEST_PROGRAM.exe!%関数名%

    BUCKET_ID:  APPLICATION_FAULT_STATUS_BREAKPOINT_TEST_PROGRAM!%関数名%+c1

    ANALYSIS_SOURCE:  UM

    FAILURE_ID_HASH_STRING:  um:status_breakpoint_80000003_TEST_PROGRAM.exe!%関数名%

    FAILURE_ID_HASH:  {84728f01-d7b4-5e6a-087c-8b7807f183b0}

    Followup: MachineOwner
    ---------


    • 編集済み supao 2019年5月23日 2:59 OSバージョン修正
    2019年5月23日 2:58

回答

  • E5-2671 v4というプロセッサーはIntel公式には掲載されていない特別モデルのようです。ググるとNECのftサーバがヒットしました。ドキュメントを読むと

    *1 本機では、以下の機能はサポートしておりません。
      ...
      ・Intel(R) AVX (Advanced Vector Extensions)
      ・Intel(R) AVX2 (Advanced Vector Extensions 2) 

    機種が一致しているかはわかりませんが、同様の条件がある場合、エラーが発生している vxorps  xmm0,xmm0,xmm0 という命令は実行することができません。

    例外コード STATUS_ILLEGAL_INSTRUCTION(0xc000001d)も実行しているプロセッサーにとって不正な命令に遭遇した際に発生するものです。

    解決するためには当該プログラムのコンパイルオプションから /arch:AVX を外してコンパイルし直す必要があります。

    • 回答としてマーク supao 2019年5月27日 1:57
    2019年5月23日 4:21

すべての返信

  • 肝心の発生したエラーコードは?

    ちなみにvxorps命令の実行にはSandy Bridge以降のプロセッサーが必要ですが条件を満たしているでしょうか?

    • 回答の候補に設定 佐祐理 2019年5月27日 2:38
    2019年5月23日 3:27
  • 直接の回答ではないですが、

    エラー時のメモリダンプを取得して windbg で analyze を行ってみました。

    なにかVisual Studioのデバッグ実行でデバッグを行わない理由等ございますでしょうか?

    char comp_flag[] = "NULL";

    上記は char comp_flag[5]; と定義されますが、その範囲を超えて文字列が代入されることはないでしょうか?

    2019年5月23日 3:33
  • 佐祐理さま

    エラーコードですが、イベントログには以下のように出力されております。
    こちらで回答になりますでしょうか。
      例外コード: 0xc000001d

    また、 Sandy Bridge以降の~~ の件に関しまして、
     systeminfo コマンドの結果 : Intel64 Family 6 Model 37 Stepping 1 GenuineIntel ~2300 Mhz
     マイコンピュータのプロパティ: intel(R) Xeon(R) CPU E5-2671 v4 @ 2.30GHz
    とありますが、この情報だといかがでしょうか。

    知識不足ですみません、宜しくお願い致します。

    2019年5月23日 3:54
  • kenjinote さま

    説明不足しておりすみません、visual studio でもデバッグしてみたのですが、
    windbg と同じ個所で落ちている、という情報しか読み取れなかったので、省略してしまっておりました。

    comp_flag につきましては、"'1'"  もしくは   "'0'"  しか入れないようなコードになっているので、
    大丈夫かと思います。

    2019年5月23日 3:56
  • > STACK_COMMAND:  ~0s; .ecxr ; kb

    この情報、重要です。
    "!analyze" だけでは、例外発生時の Context が表示されないので上記指示に従って、例外が発生した Thread の Context Record を確認する必要があります。
    この "~0s; .ecxr ; kb" を WinDbg 上で実行すれば、例外発生時のコールスタックが表示されるので、まずはそれを確認してみては?

    とにかく、WinDbg 上に表示されている内容をきちんと確認することが、一番重要です。

    2019年5月23日 4:12
  • E5-2671 v4というプロセッサーはIntel公式には掲載されていない特別モデルのようです。ググるとNECのftサーバがヒットしました。ドキュメントを読むと

    *1 本機では、以下の機能はサポートしておりません。
      ...
      ・Intel(R) AVX (Advanced Vector Extensions)
      ・Intel(R) AVX2 (Advanced Vector Extensions 2) 

    機種が一致しているかはわかりませんが、同様の条件がある場合、エラーが発生している vxorps  xmm0,xmm0,xmm0 という命令は実行することができません。

    例外コード STATUS_ILLEGAL_INSTRUCTION(0xc000001d)も実行しているプロセッサーにとって不正な命令に遭遇した際に発生するものです。

    解決するためには当該プログラムのコンパイルオプションから /arch:AVX を外してコンパイルし直す必要があります。

    • 回答としてマーク supao 2019年5月27日 1:57
    2019年5月23日 4:21
  • お馬鹿さま

    ご指摘頂きましたコマンド実行してみました。

    以下のような結果になったのですが、ダンプファイルを取得した方法が
    プログラム異常終了→異常終了のダイアログが表示される→その状態でタスクマネージャのプロセスタブでダンプを取得
    というやり方だったため、割り込みが入った後のスタックのように思えます。

    スタックの一番最後に記載した、%programpath%\%sourcefilename%.c @ 2559 については最初の投稿に記載がある、
    > 2559:     double            exec_t      = 0.0;
    この位置になるので、これ以上のスタック情報は無いように思えます。

    宜しくお願い致します。

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

    0:000> ~0s; .ecxr ; kb
    ntdll!NtWaitForMultipleObjects+0xa:
    000007fd`7a0e396b c3              ret
    Minidump doesn't have an exception context
    Unable to get exception context, HRESULT 0x80004002
    RetAddr           : Args to Child                                                           : Call Site
    000007fd`772f12d2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!NtWaitForMultipleObjects+0xa
    000007fd`7a03c37a : 000000d5`644d0000 000007f7`d689f000 00000000`00000000 00000000`000000e8 : KERNELBASE!WaitForMultipleObjectsEx+0xe5
    000007fd`7a03c14e : 00000000`00000080 00000000`80004005 00000000`000000d8 00000000`00000000 : kernel32!WerpReportFaultInternal+0x245
    000007fd`77370893 : 00000000`00000000 000000d5`64399e00 00000000`00000030 000000d5`64399e00 : kernel32!WerpReportFault+0x76
    000007fd`7a1c9383 : 00000000`00000000 000007fd`7a1f9db0 000007fd`7a1f9da4 000007fd`772f1e4d : KERNELBASE!UnhandledExceptionFilter+0x1d7
    000007fd`7a0f9e2e : 00000000`00000001 000007f7`d72a55b0 00000000`64399e10 000007f7`d71b0000 : ntdll!RtlUserThreadStart$filt$0+0x34
    000007fd`7a0f948d : 00000000`00000000 000000d5`6439fa50 000000d5`64399f70 000000d5`6439fa50 : ntdll!_C_specific_handler+0x8e
    000007fd`7a0fa4b8 : 000007fd`79fa0000 000000d5`6439fa20 00000000`00009cd8 000007f7`d722eac9 : ntdll!RtlpExecuteHandlerForException+0xd
    000007fd`7a0e333a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlDispatchException+0x392
    000007f7`d71d5771 : fefefefe`fefefefe fefefefe`fefefefe fefefefe`fefefefe fefefefe`fefefefe : ntdll!KiUserExceptionDispatch+0x2e
    000007f7`d71c87b0 : 000000d5`6454d5c0 000000d5`64533a20 000000d5`645408e0 000000d5`64542470 : TEST_PROGRAM!%関数名%+0xc1 [%programpath%\%sourcefilename%.c @ 2559]
    ~ 続く ~

    2019年5月23日 4:22
  • 佐祐理さま

    ありがとうございます。

    ご指摘の通り、
      サーバーは NEC 製のはずです。
      visual studio のビルドオプションで、Advanced Vector Extensions 2 (/arch:AVX2) を有効にしている。
    という状態でした。

    詳細な機種は明日確認可能なので、確認してみます。
    結果わかりましたら改めてご報告致します。

    2019年5月23日 4:40
  • > 000007f7`d71d5771 : fefefefe`fefefefe fefefefe`fefefefe fefefefe`fefefefe fefefefe`fefefefe : ntdll!KiUserExceptionDispatch+0x2e
    > 000007f7`d71c87b0 : 000000d5`6454d5c0 000000d5`64533a20 000000d5`645408e0 000000d5`64542470 : TEST_PROGRAM!%関数名%+0xc1 [%programpath%\%sourcefilename%.c @ 2559]
    
    

    ここ↑がポイントだと思います。

    該当プログラムのシンボル ファイル (pdb) とソース コードファイルは、このダンプ ファイルにあるバイナリ ファイル (exe) をビルドしたときのものと一致しているんですよね?
    (参照しているソース コードが、バイナリ ファイルのビルド後に改変したものである場合、WinDBG が表示しているソース コード箇所はあてになりません。)

    例外発生個所が "TEST_PROGRAM!%関数名%+0xc1" となっているので、例外発生個所は "TEST_PROGRAM!%関数名%" ルーチンに入ってから、かなり進んだ部分になるはずです。
    一方、WinDBG が表示しているソース コード部分はローカル変数定義部分なので、"TEST_PROGRAM!%関数名%" ルーチンが呼び出された直後部分に見えるので、いないように見えます。
    該当プログラムのシンボル ファイルが一致しているのであれば以下のコマンドで逆アセンブル情報が確認できますので、可能であればその情報を開示してみてください。

    uf TEST_PROGRAM!%関数名%

    • 編集済み お馬鹿 2019年5月23日 5:31 誤記訂正
    2019年5月23日 5:30
  • お馬鹿さま

    ありがとうございます。

    pdbやソースはビルドした時のものを使っております。
    uf コマンドで内容を確認してみました。
    結果ですが、0xd71d56b0 + 0xc1 = 0xd71d5771  になり、「 ソースの 2559 行目 : vxorps  xmm0,xmm0,xmm0」を
    実行する場所となりました。
    ※関数開始から変数を 9 個初期化しているので、進んだ場所になっているのかもしれません。

    宜しくお願い致します。

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

    0:000> uf TEST_PROGRAM!%関数名%
    TEST_PROGRAM!%関数名% [%programpath%\%sourcefilename%.c @ 2549]:
     2549 000007f7`d71d56b0 4c894c2420      mov     qword ptr [rsp+20h],r9
     2549 000007f7`d71d56b5 4c89442418      mov     qword ptr [rsp+18h],r8
     2549 000007f7`d71d56ba 4889542410      mov     qword ptr [rsp+10h],rdx
     2549 000007f7`d71d56bf 48894c2408      mov     qword ptr [rsp+8],rcx
     2549 000007f7`d71d56c4 56              push    rsi
     2549 000007f7`d71d56c5 57              push    rdi
     2549 000007f7`d71d56c6 b868240000      mov     eax,2468h
     2549 000007f7`d71d56cb e850bf0100      call    TEST_PROGRAM!__chkstk (000007f7`d71f1620)
     2549 000007f7`d71d56d0 482be0          sub     rsp,rax
     2550 000007f7`d71d56d3 48c784249800000000000000 mov qword ptr [rsp+98h],0
     2551 000007f7`d71d56df 48c744246000000000 mov   qword ptr [rsp+60h],0
     2552 000007f7`d71d56e8 48c744246800000000 mov   qword ptr [rsp+68h],0
     2553 000007f7`d71d56f1 488d8424c0000000 lea     rax,[rsp+0C0h]
     2553 000007f7`d71d56f9 488d0d18211200  lea     rcx,[TEST_PROGRAM!_pow10neg+0x22b8 (000007f7`d72f7818)]
     2553 000007f7`d71d5700 488bf8          mov     rdi,rax
     2553 000007f7`d71d5703 488bf1          mov     rsi,rcx
     2553 000007f7`d71d5706 b913000000      mov     ecx,13h
     2553 000007f7`d71d570b f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
     2554 000007f7`d71d570d c68424a000000000 mov     byte ptr [rsp+0A0h],0
     2554 000007f7`d71d5715 488d8424a1000000 lea     rax,[rsp+0A1h]
     2554 000007f7`d71d571d 488bf8          mov     rdi,rax
     2554 000007f7`d71d5720 33c0            xor     eax,eax
     2554 000007f7`d71d5722 b91b000000      mov     ecx,1Bh
     2554 000007f7`d71d5727 f3aa            rep stos byte ptr [rdi]
     2555 000007f7`d71d5729 c684246014000000 mov     byte ptr [rsp+1460h],0
     2555 000007f7`d71d5731 488d842461140000 lea     rax,[rsp+1461h]
     2555 000007f7`d71d5739 488bf8          mov     rdi,rax
     2555 000007f7`d71d573c 33c0            xor     eax,eax
     2555 000007f7`d71d573e b9ff0f0000      mov     ecx,0FFFh
     2555 000007f7`d71d5743 f3aa            rep stos byte ptr [rdi]
     2556 000007f7`d71d5745 488d442474      lea     rax,[rsp+74h]
     2556 000007f7`d71d574a 488d0ddb201200  lea     rcx,[TEST_PROGRAM!_pow10neg+0x22cc (000007f7`d72f782c)]
     2556 000007f7`d71d5751 488bf8          mov     rdi,rax
     2556 000007f7`d71d5754 488bf1          mov     rsi,rcx
     2556 000007f7`d71d5757 b905000000      mov     ecx,5
     2556 000007f7`d71d575c f3a4            rep movs byte ptr [rdi],byte ptr [rsi]
     2557 000007f7`d71d575e c744247001000000 mov     dword ptr [rsp+70h],1
     2558 000007f7`d71d5766 c784248800000000000000 mov dword ptr [rsp+88h],0
     2559 000007f7`d71d5771 c5f857c0        vxorps  xmm0,xmm0,xmm0
     2559 000007f7`d71d5775 c5fb11842490000000 vmovsd qword ptr [rsp+90h],xmm0

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

    2019年5月23日 6:05
  • ということは、佐祐理さんが指摘されているように、その環境が AVX/AVX2 の命令セットをサポートしていない可能性が高いと思います。
    該当プロジェクト プロパティの「拡張命令セットを有効にする ("Enable Enhanced Instruction Set")」を「設定なし」にした場合にどうなるか、確認したほうがいいと思います。
    2019年5月23日 7:12
  • お馬鹿さま

    ご確認ありがとうございます。

    みなさまご指摘の通り、拡張命令セットが原因である可能性が高いと思いますので、
    明日どうなるか確認したいと思いますので、結果出ましたら報告致します。

    宜しくお願い致します。

    2019年5月23日 7:31
  • みなさま

    実際の環境で確認したところ、拡張命令セットを 設定無し にしてビルドしたものが
    正常に稼働しました。
    (ハードの機種名は時間が無く確認取れませんでしたが、NEC製でした)

    助言頂き誠にありがとうございます。
    また何かありましたらどうぞ宜しくお願い致します。

    2019年5月27日 1:56