none
メモリーがREADになることができない。アプリケーションエラー RRS feed

  • 質問

  • VB6でSP5適応作成したプログラム。

    実行環境windows8.1

    「メモリーがReadになることができない」のエラーがたまにでる。

    頻発するわけではなく、エラーを出すのが非常に難しい。

    Windbgでダンプを解析。

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

    THREAD_SHA1_HASH_MOD_FUNC:  721fc2fff6ebcd2cc555735f383c2bdb365da1a0

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  c98e8cf4d072faf7c1d4e94a3ef19f7bfb3435da

    THREAD_SHA1_HASH_MOD:  8470e1a59f149abd3f77159fead6d4c3dc2ee4e4

    FAULT_INSTR_CODE:  468bf88b

    SYMBOL_STACK_INDEX:  6

    SYMBOL_NAME:  msvbvm60!IID_IVbaHost+2c021

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: msvbvm60

    IMAGE_NAME:  msvbvm60.dll

    DEBUG_FLR_IMAGE_TIMESTAMP:  49b01fc3

    STACK_COMMAND:  .ecxr ; kb

    FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_msvbvm60.dll!IID_IVbaHost

    BUCKET_ID:  INVALID_POINTER_READ_msvbvm60!IID_IVbaHost+2c021

    PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ_msvbvm60!IID_IVbaHost+2c021

    FAILURE_EXCEPTION_CODE:  c0000005

    FAILURE_IMAGE_NAME:  msvbvm60.dll

    BUCKET_ID_IMAGE_STR:  msvbvm60.dll

    FAILURE_MODULE_NAME:  msvbvm60

    BUCKET_ID_MODULE_STR:  msvbvm60

    FAILURE_FUNCTION_NAME:  IID_IVbaHost

    BUCKET_ID_FUNCTION_STR:  IID_IVbaHost

    BUCKET_ID_OFFSET:  2c021

    BUCKET_ID_MODTIMEDATESTAMP:  49b01fc3

    BUCKET_ID_MODCHECKSUM:  1552e2

    BUCKET_ID_MODVER_STR:  6.0.98.15

    BUCKET_ID_PREFIX_STR:  INVALID_POINTER_READ_

    FAILURE_PROBLEM_CLASS:  INVALID_POINTER_READ

    FAILURE_SYMBOL_NAME:  msvbvm60.dll!IID_IVbaHost

    WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/CT9000_10.exe/3.0.0.10/59b5e0e7/ntdll.dll/6.3.9600.18589/58961d3c/c0000005/00034886.htm?Retriage=1

    TARGET_TIME:  2017-10-20T02:31:40.000Z

    OSBUILD:  9600

    OSSERVICEPACK:  17031

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    OSPLATFORM_TYPE:  x86

    OSNAME:  Windows 8.1

    OSEDITION:  Windows 8.1 WinNt SingleUserTS

    USER_LCID:  0

    OSBUILD_TIMESTAMP:  2014-02-22 20:15:55

    BUILDDATESTAMP_STR:  140221-1952

    BUILDLAB_STR:  winblue_gdr

    BUILDOSVER_STR:  6.3.9600.17031

    ANALYSIS_SESSION_ELAPSED_TIME: b9e9

    ANALYSIS_SOURCE:  UM

    FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_msvbvm60.dll!iid_ivbahost

    FAILURE_ID_HASH:  {9c121a20-a3db-8286-8c4a-6b8059056924}

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

    0:000> lmvm msvbvm60
    Browse full module list
    start    end        module name
    66000000 66153000   msvbvm60   (export symbols)       msvbvm60.dll
        Loaded symbol image file: msvbvm60.dll
        Image path: C:\Windows\System32\msvbvm60.dll
        Image name: msvbvm60.dll
        Browse all global symbols  functions  data
        Timestamp:        Fri Mar  6 03:53:55 2009 (49B01FC3)
        CheckSum:         001552E2
        ImageSize:        00153000
        File version:     6.0.98.15
        Product version:  6.0.98.15
        File flags:       0 (Mask 3F)
        File OS:          4 Unknown Win32
        File type:        2.0 Dll
        File date:        00000000.00000000
        Translations:     0409.04b0
        CompanyName:      Microsoft Corporation
        ProductName:      Visual Basic
        InternalName:     MSVBVM60.DLL
        ProductVersion:   6.00.9815
        FileVersion:      6.00.9815
        FileDescription:  Visual Basic Virtual Machine
        LegalCopyright:   Copyright © 1987-2000 Microsoft Corp.
        LegalTrademarks:  Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation
        Comments:         March 5, 2009
    0:000> lmvm msvbvm60
    Browse full module list
    start    end        module name
    66000000 66153000   msvbvm60   (export symbols)       msvbvm60.dll
        Loaded symbol image file: msvbvm60.dll
        Image path: C:\Windows\System32\msvbvm60.dll
        Image name: msvbvm60.dll
        Browse all global symbols  functions  data
        Timestamp:        Fri Mar  6 03:53:55 2009 (49B01FC3)
        CheckSum:         001552E2
        ImageSize:        00153000
        File version:     6.0.98.15
        Product version:  6.0.98.15
        File flags:       0 (Mask 3F)
        File OS:          4 Unknown Win32
        File type:        2.0 Dll
        File date:        00000000.00000000
        Translations:     0409.04b0
        CompanyName:      Microsoft Corporation
        ProductName:      Visual Basic
        InternalName:     MSVBVM60.DLL
        ProductVersion:   6.00.9815
        FileVersion:      6.00.9815
        FileDescription:  Visual Basic Virtual Machine
        LegalCopyright:   Copyright © 1987-2000 Microsoft Corp.
        LegalTrademarks:  Microsoft® is a registered trademark of Microsoft Corporation. Windows(TM) is a trademark of Microsoft Corporation
        Comments:         March 5, 2009

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

    MSVBVM60.DLLの最新バージョンの適応で解決できる可能性があるのでしょうか?

    また最新バージョンはいくつなのでしょうか?

    ちなみにエラー発生後VB6SP6を適応。コンパイルはしてみましたが。

    コンパイルする機械のファイルバージョンが6.0.98.2

    これより新しいバージョンはあるのでしょうか?

    何かございましたら、アドバイスをよろしくお願いいたします。


     


    2017年11月6日 11:04

すべての返信

  • > FAILURE_EXCEPTION_CODE:  c0000005

    例外コードが 0xc0000005 だから "STATUS_ACCESS_VIOLATION" のエラー。。。つまりメモリ アクセス違反によるクラッシュです。
    msvbvm60.dll モジュールの問題とお考えのようですが、多分違うと思います。
    "STATUS_ACCESS_VIOLATION" のエラーが発生したときに処理していたのが、たまたま "msvbvm60!IID_IVbaHost+2c021" だっただけで、問題は別のところにあると思います。
    どーいうことかというと、メモリ上のコードあるいはデータを破壊するモジュールが別に存在していて、そいつが壊したメモリ領域にアクセスしたのが、たまたま "msvbvm60!IID_IVbaHost+2c021" の処理だった、ということだと思います。
    (そもそも msvbvm60.dll の問題であるなら、障害事例が多数報告されているはずだし、既に修正モジュールが公開されているはず。)

    既にダンプ ファイルは採取されているので、それをきちんと解析すれば、原因は特定できるかも。
    (個人的には、あと2~3個のダンプ ファイルがあれば、もっといいと思いますが。)
    とりあえず、提示されているダンプ ログを採取したダンプ ファイルに対して、下記コマンドを実行して見てください。
    ------------------------------
    <実行するコマンド>
    .reload
    .cls
    .logopen "C:\Users\<Logon Account Name>\dumpXX.log"
    .ecxr
    kvn
    ~*kvn
    !peb
    lmDv
    lml
    .logclose
    ------------------------------
    上記コマンドを実行すると、"C:\Users\<Logon Account Name>" フォルダに "dumpXX.log" とうテキスト ファイルが生成されます。
    この "dumpXX.log" をどこかのクラウド ストレージにコピーし、その URL をご連絡いただければ、私の方でその内容を確認します。
    なお、上記デバッガ コマンドで採取した "dumpXX.log" の中には <Logon Account Name> 等が含まれるので、必要に応じてその部分は適宜手動で削除してください。
    (それにしても、いきなりダンプ ログを上げて質問してくる人がいるなんて、ちょっとびっくり。)
    2017年11月7日 3:04
  • ありがとうございます。

    慣れていないもので、どのように質問すればいいのかわからず、いきなりのダンプログ大変申し訳ありません。

    アプリケーションログ内

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

    障害が発生しているモジュール名: ntdll.dll、バージョン: 6.3.9600.18589、タイム スタンプ: 0x58961d3c
    例外コード: 0xc0000005

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

    上記内容から、クラッシュダンプ解析のアドバイスを受けWindbgで解析してみました。

    Windgbの使用もほぼ、初めてなので手探り状態です。

    エラーの出ている環境(vb6のプログラム) Windows8.1

    VB6コンパイル環境 XP

    Windebgダンプファイル解析 windows10

    このような環境でご指導いただきましたdumpXX.logを作成いたしました。

    https://1drv.ms/u/s!AmyLyQH1mHIkuneNoZZNvvr4FskM

    お手数をおかけいたしておりますが、アドバイスの程よろしくお願い致します。



    2017年11月7日 10:52
  • このフォーラムではダンプ解析に関する質問は珍しいですし、そもそもダンプ解析を提案しただけで MVP 様たちから色々とありがたい忠告をいただくので、いきなりダンプ ログが上がっているのをみて、ちょっとびっくりしただけです。
    別に責めている訳ではないので、誤解なきよう。。。
    ところでこれって、もしかして POS かなんかの専用システムですか?
    (どーでもいいことですが、てっきりふつーの Windows PC だと思っていたので。)

    で、この AppCrash の発生頻度はどのくらいでしょうか?
    また、現在までに採取できているダンプ ファイルは一つだけでしょうか?
    提示して頂いたダンプ ログでは、ntdll.dll 内の RtlQueryInformationActivationContext() 関数内でメモリ アクセス違反が発生しているようですが、たまたまここでエラーが発生したのか、あるいは必ずここでエラーが発生するのかを、きちんと確認する必要があります。
    もし複数のダンプ ファイルを取得しているのであれば、それらダンプ ファイルを同様の手順で解析してみてください。
    一つしかダンプ ファイルが無いのであれば。。。。既にこの AppCrash が複数回発生しているのであれば、その都度エラー情報がアプリケーション ログに記録されているはずですので、過去に起きた "xx_10.exe" の AppCrash のアプリケーション ログをすべてチェックし、「例外コード」「障害が発生しているモジュール名」および「障害オフセット」が同じであるかを、確認してみてください。
    それらが毎回同じであるなら、Frame 15 の "xx_10!xx_01::Form_KeyDown" から Frame 0 の "ntdll!RtlQueryInformationActivationContext" までの処理経緯を丹念にトレースしていけば、原因ヶ所を特定できると思います。
    逆に「障害オフセット」が毎回異なるのであればメモリ破壊が疑われるので、Application Verifier (AppVerif.exe) で "xx_10.exe" プロセスを検証すれば、メモリ破壊が発生した瞬間をキャッチできると思います。
    ---------------------------------------------
    Windows SDK ツール:Application Verifier のご紹介
    https://blogs.msdn.microsoft.com/japan_platform_sdkwindows_sdk_support_team_blog/2011/05/29/windows-sdk-application-verifier/
    ---------------------------------------------

    ところで。。。
    この PC (というか POS システム?) では、"Seiko Instruments Inc." のプリンタを使用されているようですが、このプリンタは固定なのでしょうか?
    本件との関連性は全く不明ですが、スレッド 17 のスタック フレーム 05 に Code Injection が行われているような形跡があります。
    スタック領域内に Code Injection が行われているように見えるのですが、これは一般的な手法では無いように思うので、ちょっとだけ気になりました。
    (シンボルも合っているのに、"!peb" コマンドがエラーになっているのも???ですが。。。)
    2017年11月8日 3:20
  • いろいろ本当にありがとうございます。 

    説明がもれていて大変申し訳ありません。

    OSはWindows8.1ですが、POSシステムです。

    >この AppCrash の発生頻度はどのくらいでしょうか?

     発生頻度は非常にまれで、開発環境で何か月もテストして1回のみ発生しました。

     ほとんどの所がまったく発生致しませんが、月に1度ぐらいの割合で発生する所があります。

     DBGする前に、発生する所の機械を疑い一式交換してみましたが現象解決に至りませんでした。

     現在クラッシュダンプは一つしか収集できていません。

    AppCrash のアプリケーション ログをすべてチェックし、「例外コード」「障害が発生しているモジュール名」および「障害オフセット」が同じであるかを、確認してみてください

      複数回発生している機械のアプリケーションログ内には4つ発生していて例外コードオフセットは同一です。

    障害が発生しているモジュール名: ntdll.dll、バージョン: 6.3.9600.17031、タイム スタンプ: 0x53088928  

    例外コード: 0xc0000005

    障害オフセット: 0x0003dba6

     "Seiko Instruments Inc." のプリンタ

     このプリンタは固定です。

     アドバイスいろいろありがとうございます。この内容を参考に調査してみたいと思います。

    2017年11月8日 5:52
  • > 複数回発生している機械のアプリケーションログ内には4つ発生していて例外コードオフセットは同一です。

    「障害オフセット」が4つとも同じということは、毎回 ntdll!RtlQueryInformationActivationContext ルーチン内で落ちているとことです。
    (これは重要なヒントになります。)
    ntdll.dll 内の RtlQueryInformationActiveActivationContext() や RtlQueryInformationActivationContext() は非公開関数なので、まずは user32!RegisterClassExW ルーチンを手掛かりに調査すればいいと思います。
    幸いなことにターゲット システムは x86 (32 ビット) OS のようなので、スタックを漁れば RegisterClassExW() API パラメータの WNDCLASSEXW 構造体ポインタを見つけ出せるかも。
    今回提示されたダンプ ログの場合、0x0013bd78 ~ 0x0013bdb4 のどこかに、WNDCLASSEXW 構造体ポインタが格納されている可能性が高いと思います。
    (もしかしたら 0x440108e2 がそーなのかも。)
    とにかく WNDCLASSEXW 構造体ポインタを見つけ出し、各メンバに正しい情報がセットされているか、特に lpszMenuName  および lpszClassName メンバーに null-terminated string がセットされているか、確認されることをお勧めします。
    0x0013bd78 ~ 0x0013bdb4 内の確認は、"dds 0x0013bd78 0x0013bdb4" で見れます。
    で、WNDCLASSEXW 構造体ポインタかどうかの確認は。。。lpfnWndProc, lpszMenuName, lpszClassName あたりのオフセット値を手掛かりに、地道に探すしかないと思います。
    2017年11月8日 7:04
  • ありがとうございました。

    まず、Windbgの内容から地道に勉強するしかなさそうですね。

    気が遠くなりそうですが、頑張ってみます。

    2017年11月8日 10:49
  • 差し支えなければ、"dds 0x0013bd78 0x0013bdb4" の結果を提示して頂けますか?
    2017年11月8日 15:03
  • ありがとうございます。

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

    0:000> dds 0x0013bd78 0x0013bdb4
    0013bd78  0013bdb4
    0013bd7c  75f96e39 user32!CreateWindowExA+0x37
    0013bd80  00000000
    0013bd84  440108e2
    0013bd88  0000038f
    0013bd8c  00000011
    0013bd90  0000005b
    0013bd94  00000031
    0013bd98  000d03b8
    0013bd9c  00000461
    0013bda0  66000000*** ERROR: Symbol file could not be found.  Defaulted to export symbols for msvbvm60.dll - 
     msvbvm60!Ordinal951
    0013bda4  00000000
    0013bda8  00000000
    0013bdac  40000001*** ERROR: Symbol file could not be found.  Defaulted to export symbols for crpe32.dll - 
     crpe32!Ordinal935+0x1
    0013bdb0  00000000
    0013bdb4  0013bee8

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

    VB6上でCreateWindowExを使用しているところを探してみたのですが。

    使用はオブジェクトブラウザーで一つだけ

    NECFIP.LIB  FIP  CreateWindow

    これは、POS機能のPOSBIOS部分ですので、こちらにソースがありません。

    お忙しいところ本当にありがとうございます。

    よろしくお願いいたします。


    2017年11月9日 2:40
  • やっぱり 440108e2 が WNDCLASSEXW 構造体ポインタっぽいですね。

    ところで。。。
    問題のコール スタックを再確認していて気づいたのですが、user32!CreateWindowExA から直に user32!RegisterClassExW へのコールが発生していますが、これって少し違和感を感じます。
    ANSI 用の user32!CreateWindowExA から Unicode 用の user32!RegisterClassExW が直に呼び出されているのも不思議なのですが、そもそも user32!CreateWindowExA から user32!RegisterClassExW へのコールが発生しること自体???です。
    手元に Windows 8.1 環境が無いのでちょっとバージョンは異なるのですが、私の Windows 10 x64 では、user32!CreateWindowExA が user32!RegisterClassExW をコールすることはあり得ないのです。
    私の Windows 10 PC での user32.dll モジュールの実装を確認すると、user32!CreateWindowExA は user32!CreateWindowInternal を呼び出しているだけで、user32!CreateWindowInternal も user32!RegisterClassExW をコールしていません。
    さらに user32!RegisterClassExW も user32!RegisterClassExWOWW をコールしているだけで、user32!RegisterClassExWOWW が ntdll!RtlQueryInformationActiveActivationContext をコールしている形跡もない。。。。
    今回の AppCrash では、ntdll!RtlQueryInformationActivationContext 内で STATUS_ACCESS_VIOLATION が発生したのは確かなんだろうけど、そこに至るまでのコール スタックの状態が???だらけなのです。
    アプリケーション ログに記録されている「障害オフセット」の値が毎回変化するのであれば、スタック等のメモリ破壊も考えられますが、4つの AppCrash 共に「障害オフセット」は同じだということなので、その可能性も低い。。。
    (なにか根本的な部分を見落としている気がするのだけど、それが思いつかない。。。)

    というわけでお願いばかりですみませんが、下記コマンドも情報も採取してください。
    ---------------------
    <実行して欲しい WinDBG コマンド>
    dds 440108e2 l30
    dds 0013bca8 0013bee8
    !chkimg -db ntdll
    !chkimg -db user32
    uf /c user32!CreateWindowExA
    uf /c user32!RegisterClassExW
    ---------------------

    ところで下記コール スタックでの "xx_10!xx_01::INno_GotF+0x4517" の処理では、ポップアップウィンドウ等のウィンドウ作成の処理を行っているのですよね?
    該当箇所 (xx_01.frm ファイル 16299 行の直前) では、msvbvm60.dll 内のなんの機能を呼び出しているのでしょうか?
    ---------------------
    0c 0013c2f8 0147cdce 08b67040 0013c7ac 0013fad0 msvbvm60!IID_IVbaHost+0xda3c
    0d 0013c7a0 01468baf 08b67040 08b6000e 0013d36c xx_10!xx_01::INno_GotF+0x4517 [xx_01.frm @ 16299]
    ---------------------
    2017年11月9日 6:06
  • お手数をおかけいたします

    0:000> dds 440108e2 l30
    440108e2  ????????
    440108e6  ????????
    440108ea  ????????
    440108ee  ????????
    440108f2  ????????
    440108f6  ????????
    440108fa  ????????
    440108fe  ????????
    44010902  ????????
    44010906  ????????
    4401090a  ????????
    4401090e  ????????
    44010912  ????????
    44010916  ????????
    4401091a  ????????
    4401091e  ????????
    44010922  ????????
    44010926  ????????
    4401092a  ????????
    4401092e  ????????
    44010932  ????????
    44010936  ????????
    4401093a  ????????
    4401093e  ????????
    44010942  ????????
    44010946  ????????
    4401094a  ????????
    4401094e  ????????
    44010952  ????????
    44010956  ????????
    4401095a  ????????
    4401095e  ????????
    44010962  ????????
    44010966  ????????
    4401096a  ????????
    4401096e  ????????
    44010972  ????????
    44010976  ????????
    4401097a  ????????
    4401097e  ????????
    44010982  ????????
    44010986  ????????
    4401098a  ????????
    4401098e  ????????
    44010992  ????????
    44010996  ????????
    4401099a  ????????
    4401099e  ????????
    0:000> dds 0013bca8 0013bee8
    0013bca8  0013bd78
    0013bcac  75f8e9b3 user32!CreateWindowInternal+0x133
    0013bcb0  00000000
    0013bcb4  440108e2
    0013bcb8  0000038f
    0013bcbc  00000011
    0013bcc0  0000005b
    0013bcc4  00000031
    0013bcc8  000d03b8
    0013bccc  00000461
    0013bcd0  66000000 msvbvm60!Ordinal951
    0013bcd4  00000000
    0013bcd8  00000000
    0013bcdc  40000400 crpe32!Ordinal935+0x400
    0013bce0  0000c1ab
    0013bce4  034e0cc4
    0013bce8  0000038f
    0013bcec  0013bd7c
    0013bcf0  0000c1ab
    0013bcf4  00000400
    0013bcf8  01ef63d8
    0013bcfc  01ef63d8
    0013bd00  75f89a1f user32!NtUserSetWindowLong+0xa
    0013bd04  00000011
    0013bd08  00000000
    0013bd0c  00000461
    0013bd10  0000038f
    0013bd14  00000000
    0013bd18  00000031
    0013bd1c  00000000
    0013bd20  0000005b
    0013bd24  00000000
    0013bd28  00000000
    0013bd2c  00001648
    0013bd30  75f88c5d user32!NtUserRemoveProp+0xa
    0013bd34  75f88c93 user32!RemovePropW+0x25
    0013bd38  03b9042e
    0013bd3c  0000a91a
    0013bd40  00000000
    0013bd44  00000000
    0013bd48  00000000
    0013bd4c  00000000
    0013bd50  00000000
    0013bd54  00000001
    0013bd58  77dfa28c ntdll!RtlDeactivateActivationContextUnsafeFast+0x9c
    0013bd5c  03b9042e
    0013bd60  00000000
    0013bd64  ffffffff
    0013bd68  747b3f6e uxtheme!ThemePostWndProc+0x501 [d:\blue_gdr\shell\themes\uxtheme\sethook.cpp @ 630]
    0013bd6c  00000000
    0013bd70  00000001
    0013bd74  00000082
    0013bd78  0013bdb4
    0013bd7c  75f96e39 user32!CreateWindowExA+0x37
    0013bd80  00000000
    0013bd84  440108e2
    0013bd88  0000038f
    0013bd8c  00000011
    0013bd90  0000005b
    0013bd94  00000031
    0013bd98  000d03b8
    0013bd9c  00000461
    0013bda0  66000000 msvbvm60!Ordinal951
    0013bda4  00000000
    0013bda8  00000000
    0013bdac  40000001 crpe32!Ordinal935+0x1
    0013bdb0  00000000
    0013bdb4  0013bee8
    0013bdb8  6605a661 msvbvm60!IID_IVbaHost+0x2c021
    0013bdbc  00000004
    0013bdc0  0000c1ab
    0013bdc4  00000000
    0013bdc8  440108e2
    0013bdcc  0000038f
    0013bdd0  00000011
    0013bdd4  0000005b
    0013bdd8  00000031
    0013bddc  000d03b8
    0013bde0  00000461
    0013bde4  66000000 msvbvm60!Ordinal951
    0013bde8  00000000
    0013bdec  00000000
    0013bdf0  034e0cc4
    0013bdf4  00000001
    0013bdf8  6e756854
    0013bdfc  52726564
    0013be00  65543654
    0013be04  6f427478
    0013be08  00000078
    0013be0c  00000001
    0013be10  6605f74e msvbvm60!IID_IVbaHost+0x3110e
    0013be14  00000000
    0013be18  6605f74e msvbvm60!IID_IVbaHost+0x3110e
    0013be1c  00000000
    0013be20  0013be7c
    0013be24  75fbf00d user32!_except_handler4
    0013be28  2506a755
    0013be2c  fffffffe
    0013be30  0013be8c
    0013be34  75f89744 user32!DispatchClientMessage+0xb5
    0013be38  03b9042e
    0013be3c  00000082
    0013be40  00000000
    0013be44  00000000
    0013be48  01ef63ec
    0013be4c  00000010
    0013be50  50ed6e21
    0013be54  0000003b
    0013be58  0013bed8
    0013be5c  00000000
    0013be60  00000000
    0013be64  0013be88
    0013be68  03b9042e
    0013be6c  00000000
    0013be70  00000000
    0013be74  0013be50
    0013be78  00000000
    0013be7c  0013becc
    0013be80  75fbf00d user32!_except_handler4
    0013be84  2506471d
    0013be88  fffffffe
    0013be8c  0013bebc
    0013be90  75f8b2aa user32!__fnNCDESTROY+0x26
    0013be94  01ef63d8
    0013be98  00000082
    0013be9c  00000000
    0013bea0  75f8b2c8 user32!__fnNCDESTROY+0x44
    0013bea4  00000000
    0013bea8  0000003b
    0013beac  00000000
    0013beb0  034bea24
    0013beb4  034834b8
    0013beb8  00000000
    0013bebc  0013bf24
    0013bec0  77e2c9a6 ntdll!KiUserCallbackDispatcher+0x36
    0013bec4  0013bed8
    0013bec8  034806bc
    0013becc  00000000
    0013bed0  00000031
    0013bed4  0000005b
    0013bed8  6610dec0 msvbvm60!_vbaVarTextCmpLt+0x4357
    0013bedc  00000004
    0013bee0  00000011
    0013bee4  000d03b8
    0013bee8  0013bf24
    0:000> !chkimg -db ntdll
    0 errors : ntdll 
    0:000> !chkimg -db user32
    0 errors : user32 
    0:000> uf /c user32!CreateWindowExA
    user32!CreateWindowExA (75f96e02)
      user32!CreateWindowExA+0x32 (75f96e34):
        call to user32!CreateWindowInternal (75f8e87c)
    0:000> uf /c user32!RegisterClassExW
    user32!RegisterClassExW (75f8e650)
      user32!RegisterClassExW+0x16 (75f8e66a):
        call to user32!RegisterClassExWOWW (75f8ee6e)
      user32!RegisterClassExW+0x21 (75fbbfe5):
        call to ntdll!RtlSetLastWin32Error (77dff940)

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

    16298  Call TxtInSet(iNo)
    16299  For i = 0 To 3

    16298ではAPI関数を使用していました。

    ' 仮想キーボードの特定キーの状態を取得する関数
    Declare Function GetKeyState Lib "user32.dll" _
                                (ByVal nVirtKey As Long) As Integer

    このあと、テキストボックスの大きさなどを変更しています。

    API関数でエラーでしょうかね?

    よろしくお願いいたします。

    2017年11月9日 6:55
  • たびたび追加ですいません。
    下記コマンドの情報をお願い致します。
    ----------------------
    !analyze -v
    kvn
    da 0000c1ab
    db 0000c1ab l20
    ----------------------
    2017年11月9日 7:52
  • 0:000> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Exception Analysis                                   *
    *                                                                             *
    *******************************************************************************

    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for pow.ocx - 
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for posnbuz.dll - 
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for NECCashDrawerSOl.dll - 
    *** ERROR: Module load completed but symbols could not be loaded for SiiRpe1Sdk.dll
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for POSPrinterCoreSO113.dll - 
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for POSNBHS_HC56U.dll - 
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for Scn_so.dll - 
    GetUrlPageData2 (WinHttp) failed: 12002.

    DUMP_CLASS: 2

    DUMP_QUALIFIER: 400

    CONTEXT:  (.ecxr)
    eax=0cff0000 ebx=0013ba78 ecx=00000000 edx=0d472944 esi=00000000 edi=00000000
    eip=77df4886 esp=0013b950 ebp=0013b964 iopl=0         nv up ei pl nz na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
    ntdll!RtlpQueryInformationActivationContextBasicInformation+0x2c:
    77df4886 8b401c          mov     eax,dword ptr [eax+1Ch] ds:0023:0cff001c=????????
    Resetting default scope

    FAULTING_IP: 
    ntdll!RtlpQueryInformationActivationContextBasicInformation+2c
    77df4886 8b401c          mov     eax,dword ptr [eax+1Ch]

    EXCEPTION_RECORD:  (.exr -1)
    ExceptionAddress: 77df4886 (ntdll!RtlpQueryInformationActivationContextBasicInformation+0x0000002c)
       ExceptionCode: c0000005 (Access violation)
      ExceptionFlags: 00000000
    NumberParameters: 2
       Parameter[0]: 00000000
       Parameter[1]: 0cff001c
    Attempt to read from address 0cff001c

    DEFAULT_BUCKET_ID:  INVALID_POINTER_READ

    PROCESS_NAME:  xx_10.exe

    ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p

    EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%p

    EXCEPTION_CODE_STR:  c0000005

    EXCEPTION_PARAMETER1:  00000000

    EXCEPTION_PARAMETER2:  0cff001c

    FOLLOWUP_IP: 
    msvbvm60!IID_IVbaHost+2c021
    6605a661 8bf8            mov     edi,eax

    READ_ADDRESS:  0cff001c 

    BUGCHECK_STR:  INVALID_POINTER_READ

    WATSON_BKT_PROCSTAMP:  59b5e0e7

    WATSON_BKT_PROCVER:  3.0.0.10

    PROCESS_VER_PRODUCT:  XX_10

    WATSON_BKT_MODULE:  ntdll.dll

    WATSON_BKT_MODSTAMP:  58961d3c

    WATSON_BKT_MODOFFSET:  34886

    WATSON_BKT_MODVER:  6.3.9600.18589

    MODULE_VER_PRODUCT:  MicrosoftR WindowsR Operating System

    BUILD_VERSION_STRING:  6.3.9600.17031 (winblue_gdr.140221-1952)

    MODLIST_WITH_TSCHKSUM_HASH:  00e30f87637020838a025628a0720499ed49cd49

    MODLIST_SHA1_HASH:  224407cf29f821eedbbe95542392796ec6ef3e82

    NTGLOBALFLAG:  0

    APPLICATION_VERIFIER_FLAGS:  0

    PRODUCT_TYPE:  1

    SUITE_MASK:  272

    DUMP_FLAGS:  8000c07

    DUMP_TYPE:  0

    ANALYSIS_SESSION_HOST:  VOSTRO3800

    ANALYSIS_SESSION_TIME:  11-09-2017 16:53:45.0650

    ANALYSIS_VERSION: 10.0.14321.1024 x86fre

    THREAD_ATTRIBUTES: 
    OS_LOCALE:  JPN

    PROBLEM_CLASSES: 



    INVALID_POINTER_READ
        Tid    [0x164c]
        Frame  [0x00]: ntdll!RtlpQueryInformationActivationContextBasicInformation


    LAST_CONTROL_TRANSFER:  from 77df45d4 to 77df4886

    STACK_TEXT:  
    0013b964 77df45d4 0cff0000 0cff0000 0013ba78 ntdll!RtlpQueryInformationActivationContextBasicInformation+0x2c
    0013b9e4 77e1877c 00000001 0d472944 00000000 ntdll!RtlQueryInformationActivationContext+0x114
    0013ba08 75f8eb0f 00000001 0013ba78 00000008 ntdll!RtlQueryInformationActiveActivationContext+0x1c
    0013bca8 75f8e9b3 00000000 440108e2 0000038f user32!VerNtUserCreateWindowEx+0x130
    0013bd78 75f96e39 00000000 440108e2 0000038f user32!CreateWindowInternal+0x133
    0013bdb4 6605a661 00000004 0000c1ab 00000000 user32!CreateWindowExA+0x37
    WARNING: Stack unwind information not available. Following frames may be wrong.
    0013bee8 6605b5d3 440108e2 034de6cc 00000000 msvbvm60!IID_IVbaHost+0x2c021
    0013bf24 660ad0d9 00000020 034e0cc4 ffffffff msvbvm60!IID_IVbaHost+0x2cf93
    0013bf38 660ac1ab 034f4f68 00000006 034e0cc4 msvbvm60!DllCanUnloadNow+0xd427
    0013bf5c 6606cdb0 00000024 00000001 0013fad0 msvbvm60!DllCanUnloadNow+0xc4f9
    0013bf98 6606d0a1 034e0cc4 00000024 00000001 msvbvm60!IID_IVbaHost+0x3e770
    0013bfcc 6603c07c 034806bc 00000024 00000002 msvbvm60!IID_IVbaHost+0x3ea61
    0013c2f8 0147cdce 08b67040 0013c7ac 0013fad0 msvbvm60!IID_IVbaHost+0xda3c
    0013c7a0 01468baf 08b67040 08b6000e 0013d36c xx_10!frmCTuketuke01::INno_GotF+0x4517
    0013d438 0145b287 08b67040 00000000 0013d9d8 xx_10!frmCTuketuke01::SelTanka+0xd86f
    0013daa4 014537d5 08b67040 00130000 0013df34 xx_10!frmCTuketuke01::SelHinmei+0x6c0e
    0013df80 0147293b 08b67040 0b0f22dc 0013e50c xx_10!frmCTuketuke01::DspSYOUHIN+0x46d2
    0013e78c 01495691 08b67040 08b6000c 0013f858 xx_10!frmCTuketuke01::INno_LostF+0x9c9d
    0013f920 01487360 08b67040 0013f9c4 0013f978 xx_10!frmCTuketuke01::KeyCodeCheck+0xe107
    0013f9f4 01486ee8 08b67040 0d414cdc 0d414cde xx_10!frmCTuketuke01::KeyDownSub+0x436
    0013fa54 01486c10 08b67040 00000004 0013fa90 xx_10!frmCTuketuke01::KeyDset+0x26d
    0013fabc 66051d33 08b67040 0013fce4 0013fc68 xx_10!frmCTuketuke01::Form_KeyDown+0x224
    0013fae0 66052034 00502772 0013fb9c 00000006 msvbvm60!IID_IVbaHost+0x236f3
    0013faf8 6605211a 08b672d0 0013fbdc 0013fb9c msvbvm60!IID_IVbaHost+0x239f4
    0013fbec 75f8884f 00000000 00000002 00000000 msvbvm60!IID_IVbaHost+0x23ada
    036705ac 6601a5a8 00000000 6610e460 00435f50 user32!CallHookWithSEH+0x51
    036705b8 00435f50 00000000 00000000 00400000 msvbvm60!Zombie_Release+0xbb4f
    036705bc 00000000 00000000 00400000 034820a4 xx_10!__vba+0x88


    THREAD_SHA1_HASH_MOD_FUNC:  721fc2fff6ebcd2cc555735f383c2bdb365da1a0

    THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  c98e8cf4d072faf7c1d4e94a3ef19f7bfb3435da

    THREAD_SHA1_HASH_MOD:  8470e1a59f149abd3f77159fead6d4c3dc2ee4e4

    FAULT_INSTR_CODE:  468bf88b

    SYMBOL_STACK_INDEX:  6

    SYMBOL_NAME:  msvbvm60!IID_IVbaHost+2c021

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: msvbvm60

    IMAGE_NAME:  msvbvm60.dll

    DEBUG_FLR_IMAGE_TIMESTAMP:  49b01fc3

    STACK_COMMAND:  .ecxr ; kb

    FAILURE_BUCKET_ID:  INVALID_POINTER_READ_c0000005_msvbvm60.dll!IID_IVbaHost

    BUCKET_ID:  INVALID_POINTER_READ_msvbvm60!IID_IVbaHost+2c021

    PRIMARY_PROBLEM_CLASS:  INVALID_POINTER_READ_msvbvm60!IID_IVbaHost+2c021

    FAILURE_EXCEPTION_CODE:  c0000005

    FAILURE_IMAGE_NAME:  msvbvm60.dll

    BUCKET_ID_IMAGE_STR:  msvbvm60.dll

    FAILURE_MODULE_NAME:  msvbvm60

    BUCKET_ID_MODULE_STR:  msvbvm60

    FAILURE_FUNCTION_NAME:  IID_IVbaHost

    BUCKET_ID_FUNCTION_STR:  IID_IVbaHost

    BUCKET_ID_OFFSET:  2c021

    BUCKET_ID_MODTIMEDATESTAMP:  49b01fc3

    BUCKET_ID_MODCHECKSUM:  1552e2

    BUCKET_ID_MODVER_STR:  6.0.98.15

    BUCKET_ID_PREFIX_STR:  INVALID_POINTER_READ_

    FAILURE_PROBLEM_CLASS:  INVALID_POINTER_READ

    FAILURE_SYMBOL_NAME:  msvbvm60.dll!IID_IVbaHost

    WATSON_STAGEONE_URL:  http://watson.microsoft.com/StageOne/CT9000_10.exe/3.0.0.10/59b5e0e7/ntdll.dll/6.3.9600.18589/58961d3c/c0000005/00034886.htm?Retriage=1

    TARGET_TIME:  2017-10-20T02:31:40.000Z

    OSBUILD:  9600

    OSSERVICEPACK:  17031

    SERVICEPACK_NUMBER: 0

    OS_REVISION: 0

    OSPLATFORM_TYPE:  x86

    OSNAME:  Windows 8.1

    OSEDITION:  Windows 8.1 WinNt SingleUserTS

    USER_LCID:  0

    OSBUILD_TIMESTAMP:  2014-02-22 20:15:55

    BUILDDATESTAMP_STR:  140221-1952

    BUILDLAB_STR:  winblue_gdr

    BUILDOSVER_STR:  6.3.9600.17031

    ANALYSIS_SESSION_ELAPSED_TIME: 94fb

    ANALYSIS_SOURCE:  UM

    FAILURE_ID_HASH_STRING:  um:invalid_pointer_read_c0000005_msvbvm60.dll!iid_ivbahost

    FAILURE_ID_HASH:  {9c121a20-a3db-8286-8c4a-6b8059056924}

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


    2017年11月9日 7:55
  • 0:000> kvn
     # ChildEBP RetAddr  Args to Child              
    00 0013b47c 77e2a05a 75a145d8 d0000144 00000004 ntdll!KiFastSystemCallRet (FPO: [0,0,0])
    01 0013b480 75a145d8 d0000144 00000004 00000000 ntdll!NtRaiseHardError+0xa (FPO: [6,0,0])
    02 0013b51c 6601fa2e 0013b544 660ebd04 0013b54c KERNELBASE!LocalOpenPerformanceNlsText+0x1bf
    WARNING: Stack unwind information not available. Following frames may be wrong.
    03 0013ff80 0043572e 00435f50 75e817ad 7ffdb000 msvbvm60!Zombie_Release+0x10fd5
    04 0013ff94 77e12cb1 7ffdb000 89824c4a 00000000 xx_10!__vbaS+0xa
    05 0013ffdc 77e12c7f ffffffff 77e3e756 00000000 ntdll!__RtlUserThreadStart+0x2b (FPO: [SEH])
    06 0013ffec 00000000 00435724 7ffdb000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])

    0:000> da 0000c1ab
    0000c1ab  "????????????????????????????????"
    0000c1cb  "????????????????????????????????"
    0000c1eb  "????????????????????????????????"
    0000c20b  "????????????????????????????????"
    0000c22b  "????????????????????????????????"
    0000c24b  "????????????????????????????????"
    0000c26b  "????????????????????????????????"
    0000c28b  "????????????????????????????????"
    0000c2ab  "????????????????????????????????"
    0000c2cb  "????????????????????????????????"
    0000c2eb  "????????????????????????????????"
    0000c30b  "????????????????????????????????"
    0:000> db 0000c1ab l20
    0000c1ab  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????
    0000c1bb  ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ??  ????????????????

    2017年11月9日 8:00
  • ありがとうございます。

    ちょっと長いので3つにわけました。

    2017年11月9日 8:04
  • シンボル ファイルがちゃんとロードされてたから鵜呑みにしてましたが、どうやらこのコール スタック、Frame 05 よりも上の関数名は嘘っぱちみたい。。。
    つまり Frame 05 の user32!CreateWindowExA がコールしているのは user32!RegisterClassExW ぢゃない。
    今回採取してもらったスタックの中身を確認すると、user32!CreateWindowExA がコールしているのは user32!CreateWindowInternal です。
    なので、WinDBG のコールスタック出力が正しくない。。。
    使用されている WinDBG のバージョンはなんですか?
    古い WinDBG を使っていると、嘘っぱちコール スタックを表示させることがあるので、それに気づかないと結構痛い目に遭います。
    (何度も騙されるのに、また騙された。。。)

    > このあと、テキストボックスの大きさなどを変更しています。
    > API関数でエラーでしょうかね?

    多分そこ。
    ただしAPI が問題なのではなく、API コール時にセットしたパラメータに問題があるのだと思います。
    つまり "xx_10.exe" の実装の問題。

    問題を起こした起こしたスレッドが CreateWindowEx() API をコールしたのは、スタックの内容からみて間違いないと思います。
    ----------------------------------------
    CreateWindowEx function
    https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms632680(v=vs.85).aspx
    ----------------------------------------

    問題は、CreateWindowEx() API コールにセットされたパラメータ。
    断言はできませんけど、CreateWindowEx() コール時のパラメータ設定は、下記部分が該当箇所と考えられます。
    ----------------------------------------
    0013bdb4  0013bee8
    0013bdb8  6605a661 msvbvm60!IID_IVbaHost+0x2c021
    0013bdbc  00000004                      ;; dwExStyle    : WS_EX_NOPARENTNOTIFY
    0013bdc0  0000c1ab                      ;; lpClassName  : ページアウトしている
    0013bdc4  00000000                      ;; lpWindowName : NULL (未指定)
    0013bdc8  440108e2                      ;; dwStyle : WS_CHILD | WS_CLIPSIBLINGS | WS_TABSTOP | 0x8e2
    0013bdcc  0000038f                      ;; x
    0013bdd0  00000011                      ;; y
    0013bdd4  0000005b                      ;; nWidth
    0013bdd8  00000031                      ;; nHeight
    0013bddc  000d03b8                      ;; hWndParent
    0013bde0  00000461                      ;; hMenu
    0013bde4  66000000 msvbvm60!Ordinal951  ;; hInstance    : Module Handle <msvbvm60.dll>
    0013bde8  00000000                      ;; lpParam
    ----------------------------------------

    "xx_10!xx_01::INno_GotF" ルーチン内の該当箇所では、「テキストボックスの大きさなどを変更しています」とのことですが、"xx_10.exe" のシンボルはあるようですから、WinDBG の "Locals" ウィンドウ等から、このダンプ ファイルで変更しようとしている Text Box のサイズは確認できると思います。
    そのサイズが上記コール スタックに残されている nWidth および nHeight の値と一致するのであれば、上記部分が CreateWindowEx() API コール時のパラメータであることが確定できます。
    で、この推測が正しいとすると。。。。
    問題は、lpClassName メンバー部分ということになると思います。
    lpClassName が示す文字列ポインタは 0000c1ab ですが、このタイミングにおいて 0000c1ab は無効な領域。(ページアウトしているのかも。)
    つまり、イリーガルなクラス名をセットした状態で CreateWindowEx() コールをしたことが、AppCrash の原因である可能性が考えられます。
    CreateWindowEx() API コールにセットするクラス名は、"xx_10.exe" モジュール側から指定しているのでは?
    だとすると、このダンプが採取されたタイミングでは、何らかの理由で正しいクラス名がセットされていない可能性が考えられます。

    。。。という訳で、まずはこのダンプ ファイルで "xx_10.exe" が変更しようとしているテキスト ボックスのサイズを確認されることをお勧めします。
    もしかしたら、ダンプ ファイルを WinDBG で開き直して下記コマンドを実行すれば、確認できるかも。
    ----------------------------------------
    <実行するコマンド>
    .ecxr
    kvn
    .frame 0d
    dv /V
    .frame 0e
    dv /V
    .frame f
    dv /V
    .frame 10
    dv /V
    .frame 11
    dv /V
    .frame 12
    dv /V
    .frame 13
    dv /V
    .frame 14
    dv /V
    .frame 15
    dv /V
    .frame 28
    dv /V
    ----------------------------------------
    2017年11月9日 9:11
  • いろいろご迷惑をおかけしております。

    Windbgのファイルバージョンは 10.0.14321.1024 x86でした。

    >ただしAPI が問題なのではなく、API コール時にセットしたパラメータに問題があるのだと思います。

    素人の質問で大変申し訳ないのですが、

    Ret = GetKeyState(VK_KANA) のAPI関数のパラメータは CONST定義により固定でコールしております。(Public Const VK_KANA = &H15)

    CreateWindowEx() API コール時はxx_10からはコールしていないのです。

    最後に教えていただいたコマンドを実行してみました。

    気になったところは下記2行 MDは添え字定義です。

    0013e720          <virtual frame 13e78c>-0x006c                    MD = <Invalid safearray>

    0013f854          <virtual frame 13f920>-0x00cc          unnamed_var1 = 0n1 (No matching enumerant)

    有効な情報をいろいろ教えていただいているのに、素人すぎて理解が及ばず大変申し訳ありません。

    ありがとうございます。

    2017年11月9日 11:35
  • こちらの説明が至らなかったようで申しわけありませんでした。
    (最初の質問で、いきなりダンプ ログを張り付けていたので、ダンプ解析にはそれなりになれているのだろうと、勝手に思い込んでおりました。。。。申し訳ありません。)

    使用されている WinDBG はちょっと古いですね。
    ただ、デバッグ対象が Windows 8.1 のダンプなので、それでも十分だと思います。

    今回の解析対象である "xx_10.exe" のソースコード (xx_01.frm) は、解析対象の "xx_10.exe" モジュールをビルドしたときに使用したものを参照しているのでしょうか?
    どーいうことかというと、デバッグ対象である "xx_10.exe" モジュールは "Mon Sep 11 10:03:35 2017" にビルドされたものですので、参照すべき "xx_01.frm" も「それ以前」に作成したファイルでないと、WinDBG のソースコード情報と正しくシンクロしてくれません。
    参照しているソースコードは、"Mon Sep 11 10:03:35 2017" 以降に改変された "xx_01.frm" なのでは?

    一番最初に採取して頂いたダンプ ログのコール スタックに、下記出力結果がありました。
    -------------------------------------------
    05 0013bdb4 6605a661 00000004 0000c1ab 00000000 user32!CreateWindowExA+0x37
    06 0013bee8 6605b5d3 440108e2 034de6cc 00000000 msvbvm60!IID_IVbaHost+0x2c021
    07 0013bf24 660ad0d9 00000020 034e0cc4 ffffffff msvbvm60!IID_IVbaHost+0x2cf93
    08 0013bf38 660ac1ab 034f4f68 00000006 034e0cc4 msvbvm60!DllCanUnloadNow+0xd427
    09 0013bf5c 6606cdb0 00000024 00000001 0013fad0 msvbvm60!DllCanUnloadNow+0xc4f9
    0a 0013bf98 6606d0a1 034e0cc4 00000024 00000001 msvbvm60!IID_IVbaHost+0x3e770
    0b 0013bfcc 6603c07c 034806bc 00000024 00000002 msvbvm60!IID_IVbaHost+0x3ea61
    0c 0013c2f8 0147cdce 08b67040 0013c7ac 0013fad0 msvbvm60!IID_IVbaHost+0xda3c
    0d 0013c7a0 01468baf 08b67040 08b6000e 0013d36c xx_10!xx_01::INno_GotF+0x4517 [xx_01.frm @ 16299]
    0e 0013d438 0145b287 08b67040 00000000 0013d9d8 xx_10!xx_01::SelTanka+0xd86f [xx_01.frm @ 14416]
    0f 0013daa4 014537d5 08b67040 00130000 0013df34 xx_10!xx_01::SelHinmei+0x6c0e [xx_01.frm @ 13128]
    10 0013df80 0147293b 08b67040 0b0f22dc 0013e50c xx_10!xx_01::DspSYOUHIN+0x46d2 [xx_01.frm @ 10905]
    11 0013e78c 01495691 08b67040 08b6000c 0013f858 xx_10!xx_01::INno_LostF+0x9c9d [xx_01.frm @ 15244]
    12 0013f920 01487360 08b67040 0013f9c4 0013f978 xx_10!xx_01::KeyCodeCheck+0xe107 [xx_01.frm @ 19061]
    13 0013f9f4 01486ee8 08b67040 0d414cdc 0d414cde xx_10!xx_01::KeyDownSub+0x436 [xx_01.frm @ 17300]
    14 0013fa54 01486c10 08b67040 00000004 0013fa90 xx_10!xx_01::KeyDset+0x26d [xx_01.frm @ 17226]
    15 0013fabc 66051d33 08b67040 0013fce4 0013fc68 xx_10!xx_01::Form_KeyDown+0x224 [xx_01.frm @ 17195]
    -------------------------------------------

    一番左側の 16 進数値は、このコール スタックにおけるフレーム番号を示していますが、フレーム 0d では "xx_10!xx_01::INno_GotF" ルーチン内での処理で "xx_01.frm" ファイル 16299 行目の「一つ手前」まで処理が行われていることを示しています。
    ここで示されている "[xx_01.frm @ 16299]" は、"Mon Sep 11 10:03:35 2017" にビルドされた時に使用された "xx_01.frm" ファイルを前提としていますので、それ以降に改変された "xx_01.frm" ファイルとはシンクロしません。

    で、私が問題視しているのは、GetKeyState() API コールではなく、そのあとに行っている「テキストボックスの大きさなどを変更しています」の処理部分です。
    "xx_10.exe" が「直接」CreateWindowEx() API コールをしていないことは、当然理解しています。
    上記に示したコールスタックでは、"xx_10.exe" が「直接」呼び出した "msvbvm60.dll" 内の何かの関数に起因して、間接的に CreateWindowEx() API コールが発生しています。
    (上記コールスタックでのフレーム 05)
    先にお伺いした話では、"xx_01.frm" ファイル 16299 行目近辺でテキストボックスの大きさなどを変更しているということでしたので、この間接的に発生した CreateWindowEx() API コールは、テキスト ボックスのサイズ変更によるものだと推測しています。
    この推測が正しいとすると、まず確認すべきは CreateWindowEx() API コール時にセットされたパラメータです。
    ダンプ ログから確認する限り、CreateWindowEx() API パラメータは先に提示した部分だと考えられるのですが、その確証がありません。
    ですので、"xx_10.exe" が表示させようとしているテキスト ボックスのサイズが、ダンプに残されているサイズ (0x0000005b, 0x00000031) と一致するかを確認してみては。。。というのが、前回の返信で伝えたかったことです。

    意味不明な部分があったら指摘してください。
    ツッコミを入れていただければ、可能な範囲で返信しますので。
    2017年11月10日 3:18
  • どどど素人にわかりやすい説明ありがとうございます。

    [xx_01.frm のソースは2015/10/19より変更していません。なので同一だと思っています。

    テキストボックスの大きさ変更ですが、一つのテキストボックスでその都度品名数量などを入力するので項目におおじてLEFT・WIDTHなどを変更するロジックです。

    問題になっている箇所のコーディングですが、数量入力待ちのロジックで毎回ここを通ります。

    TOP=255(0xFF)

    Height=735(0x2DF)

    Width=480(0x1E0)

    LEFT=14550(0x38D6)

    この値は数量入力の時は同一値です。

    なので、素人考えで、VB上の値セットでエラーが出るとは考えが及ばず、APIのコールのみに考えがいってしまっていました。

    いままでご説明頂いた分は、すべてこちらの脳が足りないためと理解しております。ひとつひとつ勉強させていただいております。大変助かっております。ありがとうございます。


    2017年11月10日 5:47
  • > TOP=255(0xFF)
    > Height=735(0x2DF)
    > Width=480(0x1E0)
    > LEFT=14550(0x38D6)

    これら値の単位ってなんでしょうか?
    (Device Unit ぢゃないのかな。。。)

    ところで。。。。
    先に示したコール スタックのフレーム 0d ~ 15 までのオフセット値を見て気付いたのですが、これらの値。。。ちょっと大きすぎますね。
    もしかしたら、シンボルが合っていないのかも。
    WinDBG での <Symbol File Path> は、どのように設定していますか?
    あと、"xx_10.exe" と "xx_10.pdb" のファイルのタイムスタンプって一致してますか?

    フレーム 28 の "xx_10!__vbaS+0xa" はオフセット 0xa だから、明らかに xx_10!__vbaS ルーチン内と考えられますが、フレーム 0d の "xx_10!xx_01::INno_GotF+0x4517" はオフセット値が大きすぎるので、ホントは違うメソッドの中なのかも。。。という気もします。
    となると、"xx_10.exe" シンボル ファイルが一致していない。。。ということになってしまうのですが、WinDBG でのダンプ解析は個々のバイナリ モジュール (exe, dll) に対応するシンボル ファイル (pdb) の一致が大前提です。
    xx_01.frm ファイルの Line 16299 は、INno_GotF メソッドの中なのでしょうか?
    WinDBG 上で "x /a xx_10!*" コマンドを実行したとき、シンボル情報は正しく表示されるのでしょうか?

    • 編集済み お馬鹿 2017年11月10日 7:11 追記
    2017年11月10日 6:42
  • WinDBG での <Symbol File Path> 

    SRV*C:\WINDOWS\symbols*http://msdl.microsoft.com/download/symbols;

    C:\WINDOWS\symbolsの中に(xx_10.pdb xx_10.exe)をいれてありました。

     ソースファイルの中にも同一のものがあります。

    >"xx_10.exe" と "xx_10.pdb" のファイルのタイムスタンプ

      一致しています 9/11 10:03

    >xx_01.frm ファイルの Line 16299 は、INno_GotF メソッドの中なのでしょうか? ソースコードで確認 Lin 15893~16628までがINno_GotFです。

    PGMの大きさが24081KBなのでかなり大きいPGMです。>WinDBG 上で "x xx_10!*"コマンドを実行したとき、シンボル情報は正しく表示されるのでしょうか?

    00bf683f          xx_10!frmCTuketuke304::Form_KeyUp (void)
    012c7d67          xx_10!frmCTMstKanShamei::SYAMEI_WT (void)
    00dcc11d          xx_10!frmCTLstHinMei::Form_Load (void)
    0077482f          xx_10!frmCTTagTest::CmdMeiFB_Click (void)
    00525e70          xx_10!__vba (<no parameter info>)
    00535cf4          xx_10!__vba (<no parameter info>)
    00525bf8          xx_10!__vba (<no parameter info>)

    一部抜粋上記のような状況です。

    テキストボックスの単位ですよね調べてみます。

    2017年11月10日 7:48
  • シンボル ファイルはマッチしているんですね。
    WinDBG 上で VB のデバッグはやったことが無いので、ソースコードとシンクロしたデバッグが可能かどうかわかりませんが、調査環境に WinDBG をインストールして、ライブデバッグで CreateWindowEx() API がコールされた瞬間のスタック内容をモニターすれば、ダンプのどの部分が CreateWindowEx() API パラメータなのか特定できるかも。
    調査環境用の Windows 8.1 PC が、外部ネットワークに接続可能なら、そっちの方が良いと思います。
    (Microsoft の Web Symbol Server から Public Symbol を自動ダウンロードする必要があるため、外部ネットワークに接続できないと、まともなライブデバッグもできません。)
    2017年11月10日 8:18
  • いろいろと、ありがとうございました。

    まだ解決には至っておりませんが

    地道に解析したいと思います。

    また素人質問をさせていただくことがあるかもしれませんが、その時お時間がごじましたらよろしくお願いいたします。お礼が遅くなり申し訳ありません。


    2017年11月14日 4:48
  • 先の返信でも触れましたが、正常に動作している Windows 8.1 PC 環境で、今回問題が疑われている "xx_10!xx_01::INno_GotF+0x4517" の処理が行われる際の状態をライブデバッグで確認し、その状態とダンプ ファイルに残されている状態を比較すれば、AppCrash の直接的な原因部分を特定できる可能性が高いと思います。

    一応、以下にライブ デバッグの手順を示しておきます。
    (以下は、単に私だったらこうする。。。という私案ですので、この方法が絶対的に正しい訳ではありませんし、もっと別のアプローチもあるかもしれません。)
    ----------------------------------------
    <ライブ デバッグ手順>

    1. ライブデバッグを行う PC に WinDBG をインストールする。

    2. インストールした WinDBG を立ち上げ、"Symbol File Path" の設定および "xx_10.pdb" 等の Private Symbol File をコピーしておく。

    (上記 1, 2 は、先のダンプ解析のために行ったのと、同じ手順で構いません。)

    3. "xx_10.exe" を起動しておく。

    4. WinDBG メニューバーの <File> → <Attach to a Process> をクリックする。

    5. "Attach to Process" ダイアログで、"xx_10.exe" を選択する。
       この時、"Non invasive" のチェックが外れていることを確認すること。

    6. 上記 5 で "xx_10.exe" プロセスにアタッチすると Break-in 状態になるので、下記コマンドを実行する
    +++++++++++++++++++++++++++++++
    <実行するコマンド>
    .reload
    .cls
    .logopen "C:\Users\<Logon Account Name>\xx_10_trace.log"
    bp user32!CreateWindowExA ".echo \"!!! Hit user32!CreateWindowExA !!!\"; kvn; dds @esp l10; da poi(@esp+0x08); g;"
    bl
    +++++++++++++++++++++++++++++++

    7. 上記 6 の "bl" コマンドで、正しく Break Point がセットできいるかを確認する。

    8. "g" コマンドを実行する。
    ("F5" キーの押下でも構いません。)

    9. "xx_10!xx_01::INno_GotF+0x4517" の部分を確実に通過するオペレーションを行い、ログを採取する。
    (Break point が設定されているので、動きが非常に遅くなります。)

    10. 上記 9 で目的の動作 (テキスト ボックスの表示) が行われたら、「"Ctrl" + "Break" キー」でデバッガに Break-in させ、下記コマンドにて Break Point を解除しログ ファイルを閉じる。
    +++++++++++++++++++++++++++++++
    <実行するコマンド>
    bc *
    .logclose
    +++++++++++++++++++++++++++++++

    11. 採取した "xx_10_trace.log" ファイルの内容と、ダンプ ファイルの "dds 0013bca8 0013bee8" コマンドで得られる下記部分と比較し、違いをを確認する。
    +++++++++++++++++++++++++++++++
    <"dds 0013bca8 0013bee8" コマンドの比較対象部分>

    0013bdb8  6605a661 msvbvm60!IID_IVbaHost+0x2c021
    0013bdbc  00000004
    0013bdc0  0000c1ab
    0013bdc4  00000000
    0013bdc8  440108e2
    0013bdcc  0000038f
    0013bdd0  00000011
    0013bdd4  0000005b
    0013bdd8  00000031
    0013bddc  000d03b8
    0013bde0  00000461
    0013bde4  66000000 msvbvm60!Ordinal951
    0013bde8  00000000
    +++++++++++++++++++++++++++++++
    ----------------------------------------

    なお、上記 6 での bp コマンド設定は、32 ビット プロセスを前提としています。
    (なので 64 ビット プロセスの場合、期待するログ情報は採取できません。)
    また上記手順で "xx_10.exe" プロセスをデバッガにアタッチさせると、デバッガを終了させると "xx_10.exe" プロセスも一緒に落ちます。

    諦めなければ必ず原因にたどり着けるので、頑張ってください。
    ご検討をお祈りしております。

    2017年11月14日 5:29
  • 最後に質問者のぴーまんさんに確認ですが、このエラーは(業務として)製品の品質基準上許容できないレベル(頻度、深刻度)のものなのでしょうか? もし許容できないということであれば、きちんと費用をかけて適切な技術サポートを受けられた方が良いと思います。

    許容できなくはないが、技術的興味や技術力向上のために対処をすすめたいということなら、このままここで質問を続けられても良いかと思います。


    hebikuzure


    2017年11月15日 5:24
  • フォーラム オペレーターの立花楓です。

    回答方針に関する議論については、下記の別スレッドを立てましたのでそちらで議論されるようお願いいたします。

    フォーラムへの回答方針について
    https://social.msdn.microsoft.com/Forums/ja-JP/d46446dc-94ba-4d9c-b760-711c89ebaecb?forum=suggestja

    よろしくお願いいたします。


    MSDN/TechNet Community Support 立花楓



    2017年11月15日 6:06
    モデレータ
  • 遅くなりまして申し訳ありません。

    (別トラブルで1週間いなかったものですからすみません)

    貴重なアドバイス助かっております。

    早速やってみます。

    何か私のとんでもない質問のせいで、とてつもないご迷惑をおかけしてしまっているのでしょうか?

    ご丁寧にここまでしていただいているのに申し訳ない気持ちでいっぱいです。

    何とか解決にむけて努力致します。

    ありがとうございます。

    2017年11月20日 7:48
  • 現象が起きているところでは、許容の範囲ではありません。

    もちろん、OPOSメーカーに調査依頼は出しました。

    OPOS・プリンター・それぞれに確認はしておりますが

    すべて自分の所ではないという回答でした。

    あとはマイクロソフトさんですが、マイクロソフトさんの有償サポートをどのように受ければいいのかがよくわかっていません。

    MSDNに入っていたときは、問い合わせ先がありましたが、現在切れている状態です。

    2017年11月20日 7:53
  • > 早速やってみます。
    先に提示したライブ デバッグ時のログ採取用のコマンドですが、
    「bp user32!CreateWindowExA ".echo \"!!! Hit user32!CreateWindowExA !!!\"; kvn; dds @esp l10; da poi(@esp+0x08); g;"」
    の部分はこれで一行ですので、あいだに改行を入れないようにご注意ください。
    (試していないけど、多分これで合っているはず。)

    > 何か私のとんでもない質問のせいで、
    > とてつもないご迷惑をおかけしてしまっているのでしょうか?
    ぴーまんさんのせいではありません、私のせい。。。らしいです。
    訳のわからないアラート メールが大量に飛んでしまったのでしたら、申しわけありませんでした。
    2017年11月20日 9:30
  • デバッグしてみました。これから値を確認します。

    0013bdb8  6605a661 MSVBVM60!IID_IVbaHost+0x2c021
    0013bdbc  00000004
    0013bdc0  0000c21a  エラーログ 0000c1ab
    0013bdc4  00000000
    0013bdc8  440108e2
    0013bdcc  0000038f
    0013bdd0  00000011
    0013bdd4  0000005b
    0013bdd8  00000031
    0013bddc  000803b0  エラーログ 000d03b8
    0013bde0  000000b3  エラーログ 00000461
    0013bde4  66000000 MSVBVM60!Ordinal951
    0013bde8  00000000
    0013bdec  00000000
    0013bdf0  032d92c4
    0013bdf4  00000001
    0000c21a  "????????????????????????????????"
    0000c23a  "????????????????????????????????"
    0000c25a  "????????????????????????????????"
    0000c27a  "????????????????????????????????"
    0000c29a  "????????????????????????????????"
    0000c2ba  "????????????????????????????????"
    0000c2da  "????????????????????????????????"
    0000c2fa  "????????????????????????????????"
    0000c31a  "????????????????????????????????"
    0000c33a  "????????????????????????????????"
    0000c35a  "????????????????????????????????"
    0000c37a  "????????????????????????????????"


    2017年11月20日 10:04
  • あとはマイクロソフトさんですが、マイクロソフトさんの有償サポートをどのように受ければいいのかがよくわかっていません。

    大きく分けて、プロフェッショナルサポートご利用の流れ) と プレミアサポート があります。

    プロフェッショナルサポートの方が安いのですが、こちらの Q&A にもあるように、切り分けやデバッグ支援と分類されると対象外になります。
    特定の製品・モジュールの不具合と切り分けできていないと、受けてもらえない可能性があり、シビアです。また、原因調査は対象外となっています。

    プレミアサポートは広めに対応していただけるものの、最初に百時間以上の権利をまとめて買う(年間契約)などといった初期費用がかさむ傾向にあり、初動がなかなか大変です。
    ただし、プロフェッショナルサポートではやってくれないような解析も対応してくれるので、どこに問題があるかわからないといった状態でも手伝ってもらえます。

    あとは、自分たちで調査することでかかる日数・人件費、今の課題に対する重要度、解決できないことによる損失と照らして割に合うかどうかでご判断いただくしかないかと思います。
    (おそらく、プレミアサポートは今回の1件だけでは割に合わないので、年間通じてどのくらいそういった問い合わせがありうるかといった試算も必要になります)

    ダメ元でプロフェッショナルサポートで対応可能かを確認するところからでしょうか。

    2017年11月20日 14:30
    モデレータ
  • ぴーまんさん、いつもお世話になっております。

    日本マイクロソフトの石沢と申します。

     

    弊社有償サポートのご利用を検討いただき誠にありがとうございます。

    有償サポートの内容は Azulean さんからご案内されている通りでございます。


    なお、本内容にて有償サポートをご利用いただいた際に、ご利用いただいております VB6 のアプリケーション開発については既に弊社サポートが終了していることが懸念となります。

    VB6 のサポートの詳細につきましては、以下の資料をご参照ください。

     

    Support Statement for Visual Basic 6.0 on Windows

    https://docs.microsoft.com/en-us/visualstudio/vb6/vb6-support

     

    上記状況のため、弊社有償サポートにお問い合わせいただいた際に、VB.NET への移行をお願いさせていただく可能性が非常に高いです。

    VB6 で開発を続けられるリスクもございますため、開発環境の移行もあわせてご検討いただければ幸いです。

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

    2017年11月20日 23:31
    モデレータ
  • 私のほうは何も問題ありません。(ご心配いただきありがとうございます)

    ご指示いただいた内容ですが、改行入れずに実行しております。

    >この間接的に発生した CreateWindowEx() API コールは、テキスト ボックスのサイズ変更によるものだと推測

    今回のエラーについて

    〇テキストボックスの値の変更で内部的に上記APIが呼ばれる

    〇その時の値のパラメータが範囲外の値である

    〇アプリケーションエラーが起きる

    このような内容であっていますでしょうか?

    理解が違っていたら、誠に申し訳ありません。

    もしあっていましたら素朴な疑問が

    テキストボックスの値変更 VB6上での変更なので

    基本コンパイルエラーまたは、実行時エラーとなるのではないかと

    またこのロジックは通常毎回通るロジックです。

    OS(XP)SP2同等 の場合現象起きず。 (MicrosoftWindowsXP Embedded SP2)

    OS(XP)SP3同等の場合特定の場所で繰り返し起きる(Embedded for Point of Service)

    OS(WIndows8.1)同等の場合特定の場所で繰り返し起きる

    ソフト的にはほぼ同一のものです。


    2017年11月21日 1:21
  • 現在開発はVS2012に移行しつつあります。

    ただ現在使用中のものに関しては、新しいものにすべて置き換えてくださいとはとても言えません。

    エラーの解決が必要です。

    この問題は5年ぐらい前から未解決状態です。

    発生頻度があまりに少なく(現象の起きる場所での頻度はかなり高い業務に支障あり)

    開発環境でエラーを出すことができなくて現在に至っております。

    2017年11月21日 1:32
  • ありがとうございます。

    連絡してみます。

    2017年11月21日 2:16
  • > 今回のエラーについて
    > 〇テキストボックスの値の変更で内部的に上記APIが呼ばれる
    > 〇その時の値のパラメータが範囲外の値である
    > 〇アプリケーションエラーが起きる
    > このような内容であっていますでしょうか?

    上記は私の推測であり、まだ何もわかっていません。
    先のダンプ解析でわかっていることは、"xx_10.exe" アプリでの処理をトリガとして CreateWindowExA() API コールが発生し、その延長上で "STATUS_ACCESS_VIOLATION" のエラーが発生している。。。ということだけです。
    なので、何が "STATUS_ACCESS_VIOLATION" エラーを引き起こす要因になっているのかを特定するために、色々と提案をしている訳です。
    先のダンプ解析から、msvbvm60.dll から CreateWindowExA() API コールが発行される際に、この API の 2nd パラメータ lpClassName にセットされるクラス名文字列が正しくセットされないケースがあるのでは。。。と考えライブ デバッグを提案したのですが、提示していただいたログからは、この推測も外れたようです。
    (この CreateWindowExA() API コール時の 2nd パラメータ lpClassName にセットされている値は、文字列ポインタではなく、クラス アトム値であると考えられます。)
    という訳で、また振り出しに戻ってしまいました。。。。
    (相変わらず有効な助言ができず、申しわけありません。)

    で、いくつか確認させて頂きたいのですが。。。。
    ----------------------------------------
    <確認したい内容>

    1. 先に提示したライブ デバッグ用のコマンドを設定しアプリ側で再現用のオペレーションを行った場合、「デバッガ上にログが出力された直後」に何かのウィンドウが表示されるはずだと思っていたのですが、何もウィンドウは表示されなかったのでしょうか?

    2. 上記1でなにかのウィンドウが表示されていた場合、それは先の話で出来てきた「テキスト ウィンドウ」だったのでしょうか?

    3. 先に提示したライブ デバッグ用のコマンドを設定した場合、CreateWindowExA() API コールが発生した瞬間にコール スタックをデバッガ上に出力するはずなのですが、表示されなかったのでしょうか?

    4. 「OS(XP)SP2同等 の場合現象起きず。」とありますが、その環境にインストールされている msvbvm60.dll モジュールは、問題が発生している環境と同じものでしょうか?

    5. ダンプ ファイルに対して下記コマンドを実行し、その出力結果を教えてください。
    dds 0013b964 0013bdb4
    ----------------------------------------
    2017年11月21日 3:10

  • 1.表示されていないように思いますが、再度実行して確認してみます。

    2.3.再度じっこうしてから連絡いたします。

    4.msvbvm60.dll  すべてバージョンが違っていました。

    6.0.96.90 SP2

    6.0.98.2  SP3

    6.0.98.15 8.1

    5.Windbgでファイルを開こうとすると「Win32errorOn87」パラメータが間違っていますとでてしまいます。

    ====ログをメモで開いたところ最後

    ModLoad: 07e70000 07e79000   C:\Program Files\xx\zROUND.dll
    !!! Hit user32!CreateWindowExA !!!
     # ChildEBP RetAddr  Args to Child              
    00 0013bdb4 6605a661 00000004 0000c21a 00000000 USER32!CreateWindowExA (FPO: [Non-Fpo])
    WARNING: Stack unwind information not available. Following frames may be wrong.
    01 0013bee8 6605b5d3 440108e2 032c40f4 00000000 MSVBVM60!IID_IVbaHost+0x2c021
    02 0013bf24 660ad0d9 00000020 032d92c4 ffffffff MSVBVM60!IID_IVbaHost+0x2cf93
    03 0013bf38 660ac1ab 032d7818 00000006 032d92c4 MSVBVM60!DllCanUnloadNow+0xd427
    04 0013bf5c 6606cdb0 00000024 00000001 0013fad0 MSVBVM60!DllCanUnloadNow+0xc4f9
    05 0013bf98 6606d0a1 032d92c4 00000024 00000001 MSVBVM60!IID_IVbaHost+0x3e770
    06 0013bfcc 6603c07c 02a906bc 00000024 00000002 MSVBVM60!IID_IVbaHost+0x3ea61
    07 0013c2f8 0147cdce 088d8538 0013c7ac 0013fad0 MSVBVM60!IID_IVbaHost+0xda3c
    08 0013c7a0 01468baf 088d8538 088d000e 0013d36c XX_10!XX_01::INno_GotF+0x4517 [01.frm @ 16299]
    09 0013d438 0145b287 088d8538 00000000 0013d9d8 XX_10!XX_01::SelTanka+0xd86f [01.frm @ 14416]
    0a 0013daa4 014537d5 088d8538 00130000 0013df34 XX_10!XX_01::SelHinmei+0x6c0e [01.frm @ 13128]
    0b 0013df80 0147293b 088d8538 0ae2ee5c 0013e50c XX_10!XX_01::DspSYOUHIN+0x46d2 [01.frm @ 10905]
    0c 0013e78c 01495691 088d8538 088d000c 0013f858 XX_10!XX_01::INno_LostF+0x9c9d [01.frm @ 15244]
    0d 0013f920 01487360 088d8538 0013f9c4 0013f978 XX_10!XX_01::KeyCodeCheck+0xe107 [01.frm @ 19061]
    0e 0013f9f4 01486ee8 088d8538 0ad7cc88 0ad7cc8a XX_10!XX_01::KeyDownSub+0x436 [01.frm @ 17300]
    0f 0013fa54 01486c10 088d8538 00000011 0013fa90 XX_10!XX_01::KeyDset+0x26d [01.frm @ 17226]
    10 0013fabc 66051d33 088d8538 0013fce4 0013fc68 XX_10!XX_01::Form_KeyDown+0x224 [01.frm @ 17195]
    11 0013fae0 66052034 00502772 0013fb9c 00000006 MSVBVM60!IID_IVbaHost+0x236f3
    12 0013faf8 6605211a 088d87c8 0013fbdc 0013fb9c MSVBVM60!IID_IVbaHost+0x239f4
    13 0013fbec 7663884f 00000000 00000002 00000000 MSVBVM60!IID_IVbaHost+0x23ada
    14 0013fc24 6605fe39 032be874 0000000f 0013fc44 USER32!CallHookWithSEH+0x51 (FPO: [Non-Fpo])
    15 0013fc70 6605fbe2 032be874 00090452 00000100 MSVBVM60!IID_IVbaHost+0x317f9
    16 0013fca0 6605ce30 032be874 0013fcdc 0013fce0 MSVBVM60!IID_IVbaHost+0x315a2
    17 0013fcd0 6605f97d 032d92c4 00090452 00000100 MSVBVM60!IID_IVbaHost+0x2e7f0
    18 0013fd2c 766375b3 00090452 00000100 00000023 MSVBVM60!IID_IVbaHost+0x3133d
    19 0013fd58 766377b8 6605f74e 00090452 00000100 USER32!_InternalCallWinProc+0x23
    1a 0013fdd8 766379e6 00090452 00000100 00000023 USER32!UserCallWinProcCheckWow+0x110 (FPO: [SEH])
    1b 0013fe38 7664137b 0013fe80 6600a6c8 0013fe58 USER32!DispatchMessageWorker+0x1a1 (FPO: [Non-Fpo])
    1c 0013fe40 6600a6c8 0013fe58 ffffffff 02a91e54 USER32!DispatchMessageA+0x10 (FPO: [Non-Fpo])
    1d 0013fe80 6600a63f ffffffff 02a91e7c 02a90000 MSVBVM60!_vbaStrToAnsi+0x2f1
    1e 0013fec4 6600a51d 02a91f4c ffffffff 00000488 MSVBVM60!_vbaStrToAnsi+0x268
    1f 0013fee0 6600a4e8 02a91e78 02a91f4c ffffffff MSVBVM60!_vbaStrToAnsi+0x146
    20 0013ff04 66003644 ffffffff 00435724 76a9179b MSVBVM60!_vbaStrToAnsi+0x111
    21 0013ff80 0043572e 00435f50 76a917ad 7ffdd000 MSVBVM60!ThunRTMain+0xa0
    22 0013ff94 771e2cb1 7ffdd000 2e05d9f6 00000000 XX_10!__vbaS+0xa
    23 0013ffdc 771e2c7f ffffffff 7720e779 00000000 ntdll!__RtlUserThreadStart+0x2b (FPO: [SEH])
    24 0013ffec 00000000 00435724 7ffdd000 00000000 ntdll!_RtlUserThreadStart+0x1b (FPO: [Non-Fpo])
    0013bdb8  6605a661 MSVBVM60!IID_IVbaHost+0x2c021
    0013bdbc  00000004
    0013bdc0  0000c21a
    0013bdc4  00000000
    0013bdc8  440108e2
    0013bdcc  0000038f
    0013bdd0  00000011
    0013bdd4  0000005b
    0013bdd8  00000031
    0013bddc  000803b0
    0013bde0  000000b3
    0013bde4  66000000 MSVBVM60!Ordinal951
    0013bde8  00000000
    0013bdec  00000000
    0013bdf0  032d92c4
    0013bdf4  00000001
    0000c21a  "????????????????????????????????"
    0000c23a  "????????????????????????????????"
    0000c25a  "????????????????????????????????"
    0000c27a  "????????????????????????????????"
    0000c29a  "????????????????????????????????"
    0000c2ba  "????????????????????????????????"
    0000c2da  "????????????????????????????????"
    0000c2fa  "????????????????????????????????"
    0000c31a  "????????????????????????????????"
    0000c33a  "????????????????????????????????"
    0000c35a  "????????????????????????????????"
    0000c37a  "????????????????????????????????"
    (488.1688): Break instruction exception - code 80000003 (first chance)
    eax=7fead000 ebx=00000000 ecx=00000000 edx=77235c90 esi=76a9179b edi=77235c90
    eip=771fc8d0 esp=0963ff5c ebp=0963ff88 iopl=0         nv up ei pl zr na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
    ntdll!DbgBreakPoint:
    771fc8d0 cc              int     3
    0:006> bc*
    0:006> .logclose

    2017年11月21日 3:54
  • 連絡してみましたが、VB6ではサポートできませんとの回答でした。
    2017年11月21日 5:21
  • > 4.msvbvm60.dll  すべてバージョンが違っていました。
    > 6.0.96.90 SP2
    > 6.0.98.2  SP3
    > 6.0.98.15 8.1

    ということは、"msvbvm60.dll" モジュール依存である可能性も、完全に否定はできませんね。。。
    ただ、これらのバージョンは各 OS に同梱されている Inbox モジュールだと思われるので、バージョン依存の可能性は低いとは思うのです。
    (一番初めの返信では、msvbvm60.dll モジュールの問題では無いとお伝えしましたが、先入観より誤っているかもしれないコメントをしてしまい、申しわけありませんでした。)
    msvbvm60.dll モジュールの最新バージョンは、下記サイトで提供されているようなので、これで試してみるといいかもしれません。
    (Windows 7 までのサポートとなっているようですが、多分 Windows 8.1 にもインストール可能だと思います。)
    ----------------------------------------
    FIX: The caption is shown for a BorderStyle-0 style frame control that is put in a Visual Basic 6-based ActiveX control when you load the control in Internet Explorer 9
    https://support.microsoft.com/ja-jp/help/2575928/fix-the-caption-is-shown-for-a-borderstyle-0-style-frame-control-that

    Msvbvm60.dll    6.0.98.32
    ----------------------------------------

    今回問題となっている AppCrash と上記サポート技術情報で説明されている現象は異なるのですが、上記サイト情報を読む限り WM_CHANGEUISTATE メッセージがトリガとなっているようです。
    AppCrash 時に採取されたダンプ ファイルでの、問題を起こしたスレッドのコールスタックでも、DispatchMessage() API コールが介在しているので、多分 Window Message に関する情報が残っていると思います。
    ですので下記コマンドにて、問題を起こしたスレッドが何の Window Message を処理していたのか、確認してみると良いかもしれません。
    ----------------------------------------
    <ダンプ ファイルでの Window Message の確認方法>
    1. WinDBG で、AppCrash 時に採取されたダンプ ファイルを開く。

    2. 下記コマンドを実行する。
    ++++++++++++++++++++++++++++++
    <実行するコマンド>
    .reload
    .cls
    .ecxr
    kvn
    ++++++++++++++++++++++++++++++

    上記コマンドにより表示されたコールスタックに、下記フレームが存在していることを確認する。
    21 0013fe38 75f9137b 0013fe80 6600a6c8 0013fe58 user32!DispatchMessageW+0x1bb
    22 0013fe40 6600a6c8 0013fe58 ffffffff 03481e54 user32!DispatchMessageA+0x10

    3. 上記2で、Frame 21, 22 が表示されているのを確認したら、下記コマンドを実行する。
    ++++++++++++++++++++++++++++++
    <実行するコマンド>
    dds 0013fe58 l10
    dds 0013fe80 l10
    ++++++++++++++++++++++++++++++
    このコマンド出力結果を教えてください。

    ++++++++++++++++++++++++++++++
    <参考情報>
    MSG structure
    https://msdn.microsoft.com/ja-jp/library/windows/desktop/ms644958(v=vs.85).aspx
    ++++++++++++++++++++++++++++++
    ----------------------------------------

    > 5.Windbgでファイルを開こうとすると
    > 「Win32errorOn87」パラメータが間違っていますとでてしまいます。

    提示されているのは、お願いした「ダンプ ファイルに対する dds 0013b964 0013bdb4 コマンドの出力結果」ではなく、「ライブ デバッグ時に採取したトレース ログ」では?
    ところで、ライブ デバッグを実施した PC では、問題現象は発生していないんですよね?
    問題が起きている PC とライブ デバッグを実施した PC では、user32.dll モジュールが異なっている可能性がある (user32 モジュールが介在するコール スタックの状態が微妙に異なる) ので、user32.dll モジュールのバージョンおよびタイムスタンプを確認してみてください。
    2017年11月21日 6:32
  • >上記コマンドにより表示されたコールスタックに、下記フレームが存在していることを確認する。21 0013fe38

    >75f9137b 0013fe80 6600a6c8 0013fe58 user32!DispatchMessageW+0x1bb

    22 0013fe40 6600a6c8 0013fe58 ffffffff 03481e54 user32!DispatchMessageA+0x10

    残念ながらありません。

    0013fae0 66052034 00502772 0013fb9c 00000006 msvbvm60!IID_IVbaHost+0x236f3
    17 0013faf8 6605211a 08b672d0 0013fbdc 0013fb9c msvbvm60!IID_IVbaHost+0x239f4
    18 0013fbec 75f8884f 00000000 00000002 00000000 msvbvm60!IID_IVbaHost+0x23ada
    19 036705ac 6601a5a8 00000000 6610e460 00435f50 user32!CallHookWithSEH+0x51
    1a 036705b8 00435f50 00000000 00000000 00400000 msvbvm60!Zombie_Release+0xbb4f
    1b 036705bc 00000000 00000000 00400000 034820a4 xx_10!__vba+0x88
    0:000> dds 0013fe58 l10
    0013fe58  03b9042e
    0013fe5c  00000100
    0013fe60  00000056
    0013fe64  002f0001
    0013fe68  0050b408 CT9000_10!__vba+0x40f8
    0013fe6c  0000001d
    0013fe70  000002ed
    0013fe74  03480000
    0013fe78  00000000
    0013fe7c  034805ac
    0013fe80  0013fec4
    0013fe84  6600a63f msvbvm60!_vbaStrToAnsi+0x268
    0013fe88  ffffffff
    0013fe8c  03481e7c
    0013fe90  03480000
    0013fe94  03481e74

    >ところで、ライブ デバッグを実施した PC では、問題現象は発生していないんですよね?

    問題なく実行できています。エラーも出ていません。

    現在の環境を少しご説明します。

    エラーの出たPC ライブデバッグしているPCは同一です。(Windows8.1)

    最初に上記PCで出たエラーログを解析していたのがWindows10

    (この時上記PCにWindbgをインストールしていなかったので)

    > 5.Windbgでファイルを開こうとすると

    すみません、クラッシュログのほうですね。


    2017年11月21日 9:13
  • 0:000> dds 0013b964 0013bdb4
    0013b964  0013b9e4
    0013b968  77df45d4 ntdll!RtlQueryInformationActivationContext+0x114
    0013b96c  0cff0000
    0013b970  0cff0000
    0013b974  0013ba78
    0013b978  00000008
    0013b97c  00000000
    0013b980  89820a72
    0013b984  ffff0000
    0013b988  00000000
    0013b98c  0000c1ab
    0013b990  00000000
    0013b994  00000000
    0013b998  00000000
    0013b99c  00000000
    0013b9a0  00000000
    0013b9a4  00000004
    0013b9a8  00000000
    0013b9ac  50ed6929
    0013b9b0  00000000
    0013b9b4  00000000
    0013b9b8  0cff0000
    0013b9bc  00000000
    0013b9c0  00000000
    0013b9c4  00000001
    0013b9c8  0d3e7bd0
    0013b9cc  0013b980
    0013b9d0  0013b514
    0013b9d4  0013c2d8
    0013b9d8  77e32790 ntdll!_except_handler4
    0013b9dc  fe7bdec6
    0013b9e0  00000000
    0013b9e4  0013ba08
    0013b9e8  77e1877c ntdll!RtlQueryInformationActiveActivationContext+0x1c
    0013b9ec  00000001
    0013b9f0  0d472944
    0013b9f4  00000000
    0013b9f8  00000001
    0013b9fc  0013ba78
    0013ba00  00000008
    0013ba04  00000000
    0013ba08  0013bca8
    0013ba0c  75f8eb0f user32!VerNtUserCreateWindowEx+0x130
    0013ba10  00000001
    0013ba14  0013ba78
    0013ba18  00000008
    0013ba1c  00000000
    0013ba20  440108e2
    0013ba24  80000004
    0013ba28  00000000
    0013ba2c  01cd0120
    0013ba30  00000000
    0013ba34  00000000
    0013ba38  00000000
    0013ba3c  00000000
    0013ba40  00000000
    0013ba44  0000005b
    0013ba48  66000000 msvbvm60!Ordinal951
    0013ba4c  0000038f
    0013ba50  00000000
    0013ba54  000d03b8
    0013ba58  40000000*** ERROR: Symbol file could not be found.  Defaulted to export symbols for crpe32.dll - 
     crpe32!Ordinal935
    0013ba5c  00000011
    0013ba60  80000004
    0013ba64  00000031
    0013ba68  00000000
    0013ba6c  00000000
    0013ba70  440108e2
    0013ba74  00000461
    0013ba78  00000000
    0013ba7c  00000000
    0013ba80  00000000
    0013ba84  00000000
    0013ba88  00000000
    0013ba8c  00000000
    0013ba90  00000000
    0013ba94  00000000
    0013ba98  0000c1ab
    0013ba9c  40000400 crpe32!Ordinal935+0x400
    0013baa0  0013bb0c
    0013baa4  75f9b054 user32!FreeLookasideEntry+0x40
    0013baa8  00270000
    0013baac  00000000
    0013bab0  75f90355 user32!NtUserSetWindowFNID+0xa
    0013bab4  75fb173b user32!ECNcDestroyHandler+0x8c
    0013bab8  03b9042e
    0013babc  00004000
    0013bac0  03b9042e
    0013bac4  01ef63d8
    0013bac8  08bdf278
    0013bacc  75fb169f user32!EditWndProc+0x285
    0013bad0  01ef63d8
    0013bad4  03b9042e
    0013bad8  75fb14ef user32!EditWndProc+0xbc
    0013badc  03b9042e
    0013bae0  00000001
    0013bae4  03b9042e
    0013bae8  00000000
    0013baec  0000ffff
    0013baf0  034e0cc4
    0013baf4  000000d3
    0013baf8  00000002
    0013bafc  0013be20
    0013bb00  75fbf00d user32!_except_handler4
    0013bb04  50ed6a71
    0013bb08  fffffffe
    0013bb0c  0013bb30
    0013bb10  75fb1427 user32!EditWndProcWorker+0x63
    0013bb14  01ef63d8
    0013bb18  00000082
    0013bb1c  00000000
    0013bb20  00000000
    0013bb24  00000001
    0013bb28  77dfa28c ntdll!RtlDeactivateActivationContextUnsafeFast+0x9c
    0013bb2c  00000082
    0013bb30  0013bb54
    0013bb34  75fb24ba user32!EditWndProcA+0x59
    0013bb38  01ef63d8
    0013bb3c  00000082
    0013bb40  00000000
    0013bb44  00000000
    0013bb48  00000001
    0013bb4c  00000001
    0013bb50  00000000
    0013bb54  0013bb80
    0013bb58  75f875b3 user32!_InternalCallWinProc+0x23
    0013bb5c  03b9042e
    0013bb60  00000082
    0013bb64  00000000
    0013bb68  00000000
    0013bb6c  00000001
    0013bb70  dcbaabcd
    0013bb74  00000082
    0013bb78  00000000
    0013bb7c  00000001
    0013bb80  0013bc00
    0013bb84  75f877b8 user32!UserCallWinProcCheckWow+0x110
    0013bb88  77e3db60 ntdll!NtdllEditWndProc_A
    0013bb8c  898208ba
    0013bb90  0013bc00
    0013bb94  75f875fa user32!UserCallWinProcCheckWow+0x253
    0013bb98  75f877cc user32!UserCallWinProcCheckWow+0x124
    0013bb9c  50ed6cad
    0013bba0  03b9042e
    0013bba4  77e3db60 ntdll!NtdllEditWndProc_A
    0013bba8  00000082
    0013bbac  00000024
    0013bbb0  00000001
    0013bbb4  0013bde4
    0013bbb8  00000000
    0013bbbc  00000070
    0013bbc0  ffec421b
    0013bbc4  ffffffff
    0013bbc8  75f87737 user32!UserCallWinProcCheckWow+0x97
    0013bbcc  75f875fa user32!UserCallWinProcCheckWow+0x253
    0013bbd0  00000000
    0013bbd4  00000000
    0013bbd8  03b9042e
    0013bbdc  00000001
    0013bbe0  77e3db60 ntdll!NtdllEditWndProc_A
    0013bbe4  00000000
    0013bbe8  0013bc34
    0013bbec  03b9042e
    0013bbf0  0013be20
    0013bbf4  75fbf00d user32!_except_handler4
    0013bbf8  2506a755
    0013bbfc  fffffffe
    0013bc00  0013bc2c
    0013bc04  75fb9a24 user32!CallWindowProcA+0x5e
    0013bc08  03b9042e
    0013bc0c  00000082
    0013bc10  00000000
    0013bc14  00000000
    0013bc18  00000000
    0013bc1c  00000000
    0013bc20  03b9042e
    0013bc24  034e0cc4
    0013bc28  00000082
    0013bc2c  0013bc98
    0013bc30  6605d082 msvbvm60!IID_IVbaHost+0x2ea42
    0013bc34  03b9042e
    0013bc38  00000082
    0013bc3c  6605d6ee msvbvm60!IID_IVbaHost+0x2f0ae
    0013bc40  03b9042e
    0013bc44  89820fee
    0013bc48  66000000 msvbvm60!Ordinal951
    0013bc4c  00000004
    0013bc50  00000003
    0013bc54  034e0cc4
    0013bc58  66000080 msvbvm60!Ordinal951+0x80
    0013bc5c  00000000
    0013bc60  0013bc44
    0013bc64  d5923c7c
    0013bc68  0013bcc4
    0013bc6c  77e32790 ntdll!_except_handler4
    0013bc70  fe7bdfbe
    0013bc74  fffffffe
    0013bc78  0013bc98
    0013bc7c  77df1f8b ntdll!RtlImageNtHeader+0x1b
    0013bc80  00000001
    0013bc84  66000000 msvbvm60!Ordinal951
    0013bc88  00000000
    0013bc8c  00000000
    0013bc90  0013bc94
    0013bc94  66000080 msvbvm60!Ordinal951+0x80
    0013bc98  0013bcd4
    0013bc9c  75f8e478 user32!RtlGetExpWinVer+0x2e
    0013bca0  75f8e4b0 user32!RtlGetExpWinVer+0x66
    0013bca4  50ed6c05
    0013bca8  0013bd78
    0013bcac  75f8e9b3 user32!CreateWindowInternal+0x133
    0013bcb0  00000000
    0013bcb4  440108e2
    0013bcb8  0000038f
    0013bcbc  00000011
    0013bcc0  0000005b
    0013bcc4  00000031
    0013bcc8  000d03b8
    0013bccc  00000461
    0013bcd0  66000000 msvbvm60!Ordinal951
    0013bcd4  00000000
    0013bcd8  00000000
    0013bcdc  40000400 crpe32!Ordinal935+0x400
    0013bce0  0000c1ab
    0013bce4  034e0cc4
    0013bce8  0000038f
    0013bcec  0013bd7c
    0013bcf0  0000c1ab
    0013bcf4  00000400
    0013bcf8  01ef63d8
    0013bcfc  01ef63d8
    0013bd00  75f89a1f user32!NtUserSetWindowLong+0xa
    0013bd04  00000011
    0013bd08  00000000
    0013bd0c  00000461
    0013bd10  0000038f
    0013bd14  00000000
    0013bd18  00000031
    0013bd1c  00000000
    0013bd20  0000005b
    0013bd24  00000000
    0013bd28  00000000
    0013bd2c  00001648
    0013bd30  75f88c5d user32!NtUserRemoveProp+0xa
    0013bd34  75f88c93 user32!RemovePropW+0x25
    0013bd38  03b9042e
    0013bd3c  0000a91a
    0013bd40  00000000
    0013bd44  00000000
    0013bd48  00000000
    0013bd4c  00000000
    0013bd50  00000000
    0013bd54  00000001
    0013bd58  77dfa28c ntdll!RtlDeactivateActivationContextUnsafeFast+0x9c
    0013bd5c  03b9042e
    0013bd60  00000000
    0013bd64  ffffffff
    0013bd68  747b3f6e uxtheme!ThemePostWndProc+0x501 [d:\blue_gdr\shell\themes\uxtheme\sethook.cpp @ 630]
    0013bd6c  00000000
    0013bd70  00000001
    0013bd74  00000082
    0013bd78  0013bdb4
    0013bd7c  75f96e39 user32!CreateWindowExA+0x37
    0013bd80  00000000
    0013bd84  440108e2
    0013bd88  0000038f
    0013bd8c  00000011
    0013bd90  0000005b
    0013bd94  00000031
    0013bd98  000d03b8
    0013bd9c  00000461
    0013bda0  66000000 msvbvm60!Ordinal951
    0013bda4  00000000
    0013bda8  00000000
    0013bdac  40000001 crpe32!Ordinal935+0x1
    0013bdb0  00000000
    0013bdb4  0013bee8
    2017年11月21日 9:16
  • > 残念ながらありません。

    そんなはずはありません。
    一番初め提供してもらった "dumpXX.log" にはあるのですから、同じダンプ ファイルをオープンしているのであれば、出てくるはずです。
    もう一度 "dumpXX.log" を見直して、それと同じコール スタックが表示されているか、確認し直してください。
    コール スタック情報が正しくないと、正しい解析もできません。

    確認のため、私がダウンロードした "dumpXX.log" のコール スタックを示しておきます。

    -----------------------------------------
    0:000> .ecxr
    eax=0cff0000 ebx=0013ba78 ecx=00000000 edx=0d472944 esi=00000000 edi=00000000
    eip=77df4886 esp=0013b950 ebp=0013b964 iopl=0         nv up ei pl nz na pe nc
    cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
    ntdll!RtlQueryInformationActivationContext+0x3c6:
    77df4886 8b401c          mov     eax,dword ptr [eax+1Ch] ds:0023:0cff001c=????????
    0:000> kvn
      *** Stack trace for last set context - .thread/.cxr resets it
     # ChildEBP RetAddr  Args to Child             
    WARNING: Stack unwind information not available. Following frames may be wrong.
    00 0013b964 77df45d4 0cff0000 0cff0000 0013ba78 ntdll!RtlQueryInformationActivationContext+0x3c6
    01 0013b9e4 77e1877c 00000001 0d472944 00000000 ntdll!RtlQueryInformationActivationContext+0x114
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for user32.dll -
    02 0013ba08 75f8eb0f 00000001 0013ba78 00000008 ntdll!RtlQueryInformationActiveActivationContext+0x1c
    03 0013bca8 75f8e9b3 00000000 440108e2 0000038f user32!RegisterClassExW+0x4bf
    04 0013bd78 75f96e39 00000000 440108e2 0000038f user32!RegisterClassExW+0x363
    05 0013bdb4 6605a661 00000004 0000c1ab 00000000 user32!CreateWindowExA+0x37
    06 0013bee8 6605b5d3 440108e2 034de6cc 00000000 msvbvm60!IID_IVbaHost+0x2c021
    07 0013bf24 660ad0d9 00000020 034e0cc4 ffffffff msvbvm60!IID_IVbaHost+0x2cf93
    08 0013bf38 660ac1ab 034f4f68 00000006 034e0cc4 msvbvm60!DllCanUnloadNow+0xd427
    09 0013bf5c 6606cdb0 00000024 00000001 0013fad0 msvbvm60!DllCanUnloadNow+0xc4f9
    0a 0013bf98 6606d0a1 034e0cc4 00000024 00000001 msvbvm60!IID_IVbaHost+0x3e770
    0b 0013bfcc 6603c07c 034806bc 00000024 00000002 msvbvm60!IID_IVbaHost+0x3ea61
    0c 0013c2f8 0147cdce 08b67040 0013c7ac 0013fad0 msvbvm60!IID_IVbaHost+0xda3c
    0d 0013c7a0 01468baf 08b67040 08b6000e 0013d36c xx_10!xx_01::INno_GotF+0x4517 [xx_01.frm @ 16299]
    0e 0013d438 0145b287 08b67040 00000000 0013d9d8 xx_10!xx_01::SelTanka+0xd86f [xx_01.frm @ 14416]
    0f 0013daa4 014537d5 08b67040 00130000 0013df34 xx_10!xx_01::SelHinmei+0x6c0e [xx_01.frm @ 13128]
    10 0013df80 0147293b 08b67040 0b0f22dc 0013e50c xx_10!xx_01::DspSYOUHIN+0x46d2 [xx_01.frm @ 10905]
    11 0013e78c 01495691 08b67040 08b6000c 0013f858 xx_10!xx_01::INno_LostF+0x9c9d [xx_01.frm @ 15244]
    12 0013f920 01487360 08b67040 0013f9c4 0013f978 xx_10!xx_01::KeyCodeCheck+0xe107 [xx_01.frm @ 19061]
    13 0013f9f4 01486ee8 08b67040 0d414cdc 0d414cde xx_10!xx_01::KeyDownSub+0x436 [xx_01.frm @ 17300]
    14 0013fa54 01486c10 08b67040 00000004 0013fa90 xx_10!xx_01::KeyDset+0x26d [xx_01.frm @ 17226]
    15 0013fabc 66051d33 08b67040 0013fce4 0013fc68 xx_10!xx_01::Form_KeyDown+0x224 [xx_01.frm @ 17195]
    16 0013fae0 66052034 00502772 0013fb9c 00000006 msvbvm60!IID_IVbaHost+0x236f3
    17 0013faf8 6605211a 08b672d0 0013fbdc 0013fb9c msvbvm60!IID_IVbaHost+0x239f4
    18 0013fbec 75f8884f 00000000 00000002 00000000 msvbvm60!IID_IVbaHost+0x23ada
    19 0013fc00 66052667 034cc94c 034bea24 03485c00 user32!ScrollDC+0x78
    1a 0013fc24 6605fe39 034cc94c 0000000f 0013fc44 msvbvm60!IID_IVbaHost+0x24027
    1b 0013fc70 6605fbe2 034cc94c 03b9042e 00000100 msvbvm60!IID_IVbaHost+0x317f9
    1c 0013fca0 6605ce30 034cc94c 0013fcdc 0013fce0 msvbvm60!IID_IVbaHost+0x315a2
    1d 0013fcd0 6605f97d 034e0cc4 03b9042e 00000100 msvbvm60!IID_IVbaHost+0x2e7f0
    1e 0013fd2c 75f875b3 03b9042e 00000100 00000056 msvbvm60!IID_IVbaHost+0x3133d
    1f 0013fd58 75f877b8 6605f74e 03b9042e 00000100 user32!gapfnScSendMessage+0x18b
    20 0013fdd8 75f879e6 03b9042e 00000100 00000056 user32!gapfnScSendMessage+0x390
    21 0013fe38 75f9137b 0013fe80 6600a6c8 0013fe58 user32!DispatchMessageW+0x1bb
    22 0013fe40 6600a6c8 0013fe58 ffffffff 03481e54 user32!DispatchMessageA+0x10
    23 0013fe80 6600a63f ffffffff 03481e7c 03480000 msvbvm60!_vbaStrToAnsi+0x2f1
    24 0013fec4 6600a51d 03481f4c ffffffff 00001648 msvbvm60!_vbaStrToAnsi+0x268
    25 0013fee0 6600a4e8 03481e78 03481f4c ffffffff msvbvm60!_vbaStrToAnsi+0x146
    26 0013ff04 66003644 ffffffff 00435724 75e8179b msvbvm60!_vbaStrToAnsi+0x111
    27 0013ff80 0043572e 00435f50 75e817ad 7ffdb000 msvbvm60!ThunRTMain+0xa0
    28 0013ff94 77e12cb1 7ffdb000 89824c4a 00000000 xx_10!__vbaS+0xa
    29 0013ffdc 77e12c7f ffffffff 77e3e756 00000000 ntdll!LdrRemoveLoadAsDataTable+0x191
    2a 0013ffec 00000000 00435724 7ffdb000 00000000 ntdll!LdrRemoveLoadAsDataTable+0x15f
    -----------------------------------------

    確認したいのは、上記コール スタックのフレーム 21, 22 の、DispatchMessageW() と DispatchMessageA() の部分です。

    追記

    あと。。。
    ぴーまんさんの以前のスレッドでダンプ解析を勧めた MVP の Hebikuzure さんは、ダンプ解析手法に関して私とは異なる見解をお持ちのようです。
    なのでこの方に質問すれば、私の知らない別アプローチによる解析手法を提案してくれるかもしれません。
    (現在は、このスレッドが継続中であることに気付かれていると思うので。)


    • 編集済み お馬鹿 2017年11月21日 9:41 追記
    2017年11月21日 9:31
  • 確かに変ですね。

    前回作成したLOGにはあります。

    今回は

    0:000> kbn
      *** Stack trace for last set context - .thread/.cxr resets it
     # ChildEBP RetAddr  Args to Child              
    00 0013b964 77df45d4 0cff0000 0cff0000 0013ba78 ntdll!RtlpQueryInformationActivationContextBasicInformation+0x2c
    01 0013b9e4 77e1877c 00000001 0d472944 00000000 ntdll!RtlQueryInformationActivationContext+0x114
    02 0013ba08 75f8eb0f 00000001 0013ba78 00000008 ntdll!RtlQueryInformationActiveActivationContext+0x1c
    03 0013bca8 75f8e9b3 00000000 440108e2 0000038f user32!VerNtUserCreateWindowEx+0x130
    04 0013bd78 75f96e39 00000000 440108e2 0000038f user32!CreateWindowInternal+0x133
    *** ERROR: Symbol file could not be found.  Defaulted to export symbols for msvbvm60.dll - 
    05 0013bdb4 6605a661 00000004 0000c1ab 00000000 user32!CreateWindowExA+0x37
    WARNING: Stack unwind information not available. Following frames may be wrong.
    06 0013bee8 6605b5d3 440108e2 034de6cc 00000000 msvbvm60!IID_IVbaHost+0x2c021
    07 0013bf24 660ad0d9 00000020 034e0cc4 ffffffff msvbvm60!IID_IVbaHost+0x2cf93
    08 0013bf38 660ac1ab 034f4f68 00000006 034e0cc4 msvbvm60!DllCanUnloadNow+0xd427
    09 0013bf5c 6606cdb0 00000024 00000001 0013fad0 msvbvm60!DllCanUnloadNow+0xc4f9
    0a 0013bf98 6606d0a1 034e0cc4 00000024 00000001 msvbvm60!IID_IVbaHost+0x3e770
    0b 0013bfcc 6603c07c 034806bc 00000024 00000002 msvbvm60!IID_IVbaHost+0x3ea61
    0c 0013c2f8 0147cdce 08b67040 0013c7ac 0013fad0 msvbvm60!IID_IVbaHost+0xda3c
    0d 0013c7a0 01468baf 08b67040 08b6000e 0013d36c xx_10!xx_01::INno_GotF+0x4517 [xx_01.frm @ 16299]
    0e 0013d438 0145b287 08b67040 00000000 0013d9d8 xx_10!xx_01::SelTanka+0xd86f [xx_01.frm @ 14416]
    0f 0013daa4 014537d5 08b67040 00130000 0013df34 xx_10!xx_01::SelHinmei+0x6c0e [xx_01.frm @ 13128]
    10 0013df80 0147293b 08b67040 0b0f22dc 0013e50c xx_10!xx_01::DspSYOUHIN+0x46d2 [xx_01.frm @ 10905]
    11 0013e78c 01495691 08b67040 08b6000c 0013f858 xx_10!xx_01::INno_LostF+0x9c9d [xx_01.frm @ 15244]
    12 0013f920 01487360 08b67040 0013f9c4 0013f978 xx_10!xx_01::KeyCodeCheck+0xe107 [xx_01.frm @ 19061]
    13 0013f9f4 01486ee8 08b67040 0d414cdc 0d414cde xx_10!xx_01::KeyDownSub+0x436 [xx_01.frm @ 17300]
    14 0013fa54 01486c10 08b67040 00000004 0013fa90 xx_10!xx_01::KeyDset+0x26d [xx_01.frm @ 17226]
    15 0013fabc 66051d33 08b67040 0013fce4 0013fc68 xx_10!xx_01::Form_KeyDown+0x224 [xx_01.frm @ 17195]
    16 0013fae0 66052034 00502772 0013fb9c 00000006 msvbvm60!IID_IVbaHost+0x236f3
    17 0013faf8 6605211a 08b672d0 0013fbdc 0013fb9c msvbvm60!IID_IVbaHost+0x239f4
    18 0013fbec 75f8884f 00000000 00000002 00000000 msvbvm60!IID_IVbaHost+0x23ada
    19 036705ac 6601a5a8 00000000 6610e460 00435f50 user32!CallHookWithSEH+0x51
    1a 036705b8 00435f50 00000000 00000000 00400000 msvbvm60!Zombie_Release+0xbb4f
    1b 036705bc 00000000 00000000 00400000 034820a4 xx_10!__vba+0x88

    ==========ここで終了

    前回と

    WARNING: Stack unwind information not available. Following frames may be wrong.
    00 0013b964 77df45d4 0cff0000 0cff0000 0013ba78 ntdll!RtlQueryInformationActivationContext+0x3c6

    ログは同じものをしようしています。クラッシュダンプは一つしか収集できていないので、タイムスタンプも確認してみましたが、10/2011:31で変更された形跡はないです。

    同じ情報がでてこなければ、解析しようがありませんよね。

    すみません、でもなぜだかわからないのです。

    Windbgのバージョンも確認しましたが、同一でした。

    お手数ばかりをおかけして申し訳ないです。


    2017年11月21日 11:11
  •  もう一度 "dumpXX.log" を採取しなおして、そのファイルをアップロードして頂けますか?

    2017年11月21日 23:20
  • おはようございます。

    https://1drv.ms/u/s!AmyLyQH1mHIkunqLuhzNKjN88Bzx

    申し訳ありません。

    ありがとうございます。

    貴重なお時間をかなり頂いてしまっているので大変申し訳なく思っております。

    よろしくお願い致します。



    2017年11月22日 1:33
  • 昨日、間違えてVS2012のDBGでエラーログファイルを開いてしまいました。

    (前回のログと情報が異なると判明した後です)

    下記のような内容でした。

    関係ないかもしれませんが。

    ntdll.dll!RtlpQueryInformationActivationContextBasicInformation()  不明

                 ntdll.dll!RtlQueryInformationActivationContext()    不明

                 ntdll.dll!_RtlQueryInformationActiveActivationContext@16‑()             不明

                 user32.dll!VerNtUserCreateWindowEx()     不明

                 user32.dll!CreateWindowInternal()             不明

                 user32.dll!_CreateWindowExA@48‑()          不明

                 msvbvm60.dll!6605a661()              不明

                 [下のフレームは間違っているか、または見つかりません。msvbvm60.dll に対して読み込まれたシンボルはありません。]        

                 user32.dll!___fnNCDESTROY@4‑()             不明

    >            ntdll.dll!_KiUserCallbackDispatcher@12‑() 不明

                 msvbvm60.dll!6606cdb0()              不明

                 msvbvm60.dll!6606d0a1()              不明

                 msvbvm60.dll!66066a3e()              不明

                 msvbvm60.dll!6603c07c() 不明

                 xx_10.exe!01436cf2()             不明

                 xx_10.exe!0147cdce()             不明

                 xx_10.exe!01468baf()            不明


    2017年11月22日 1:35
  • > 貴重なお時間をかなり頂いてしまっているので
    > 大変申し訳なく思っております。

    とりあえず乗り掛かった舟なので。
    (自分の勉強にもなるし。)
    もっとも、私の手に負えないと思ったら投げ出しちゃうかもしれませんが。wwww
    今回新たに提示して頂いたログはダウンロードしましたので、安全のためこのファイルは削除してください。

    ダンプ ログの内容を確認しましたが、どうやらこっちが正しいみたいです。
    (問題を起こしているスレッドのコール スタックの状態が、以前に採取してもらった "dds 0013b964 0013bdb4" コマンドの結果と一致しているので。)
    で、今回解析した結論を先に言うと。。。。
    「仮想メモリ上にロードされた "msvbvm60.dll" モジュールを破壊する悪い奴がいるかも。」
    です。
    なぜそー思うかというと。。。
    先に採取してもらったダンプ ファイルの "dds 0013b964 0013bdb4" コマンドの出力結果に、以下の部分がありました。
    ------------------------------------------------
    <"dds 0013b964 0013bdb4" コマンドの出力結果>
    0:000> dds 0013b964 0013bdb4
    ....
    0013bc6c  77e32790 ntdll!_except_handler4
    0013bc70  fe7bdfbe
    0013bc74  fffffffe
    0013bc78  0013bc98
    0013bc7c  77df1f8b ntdll!RtlImageNtHeader+0x1b
    0013bc80  00000001
    0013bc84  66000000 msvbvm60!Ordinal951
    0013bc88  00000000
    0013bc8c  00000000
    0013bc90  0013bc94
    0013bc94  66000080 msvbvm60!Ordinal951+0x80
    0013bc98  0013bcd4
    0013bc9c  75f8e478 user32!RtlGetExpWinVer+0x2e
    0013bca0  75f8e4b0 user32!RtlGetExpWinVer+0x66
    0013bca4  50ed6c05
    0013bca8  0013bd78
    0013bcac  75f8e9b3 user32!CreateWindowInternal+0x133
    0013bcb0  00000000
    0013bcb4  440108e2
    0013bcb8  0000038f
    0013bcbc  00000011
    0013bcc0  0000005b
    0013bcc4  00000031
    0013bcc8  000d03b8
    0013bccc  00000461
    0013bcd0  66000000 msvbvm60!Ordinal951
    0013bcd4  00000000
    0013bcd8  00000000
    ....
    ------------------------------------------------
    上記スタック フレームの内容は何を表しているかというと、
    「user32!CreateWindowExA → user32!CreateWindowInternal → user32!RtlGetExpWinVer → ntdll!RtlImageNtHeader」
    の順番でコールが発生したことを示しています。
    ここで着目すべきは、「0013bc6c  77e32790 ntdll!_except_handler4」の部分です。
    これは ntdll!RtlImageNtHeader ルーチン内での処理で、例外。。。即ち何かのエラーが発生したと考えられます。
    では、ntdll!RtlImageNtHeader ルーチンでは何の処理をしていたのか?
    上記スタック フレーム内に "msvbvm60.dll" のモジュール ハンドルが残されているので、"msvbvm60.dll" のファイル ヘッダー情報を読み込んでいる最中に例外が発生したと考えられます。
    つまり、"msvbvm60.dll" モジュールが壊れているのでは。。。ということです。
    ただ発生頻度がきわめて低いことから、HDD 上の "msvbvm60.dll" モジュールのファイルが壊れているとは考えにくいです。
    だとすると、仮想メモリ上にロードされた "msvbvm60.dll" のイメージ情報を壊す、お行儀の悪い何かのモジュールが存在する。。。と考えるのが妥当だと思うのです。

    とりあえず、ダンプ ファイル内の "msvbvm60.dll" モジュールがどのような状態にあるのかを確認するために、下記コマンドを実行してみてください。
    ++++++++++++++++++++++++++++++
    <実行するコマンド>
    !dh -f -s -a -e -i msvbvm60
    ++++++++++++++++++++++++++++++

    あと以前にも提案しましたが、問題現象が発生している PC 環境で、Application Verifier (AppVerif.exe) を行っておくことも、併せてお勧めします。
    2017年11月22日 4:07
  • >あと以前にも提案しましたが、問題現象が発生している PC 環境で、Application Verifier (AppVerif.exe) >を行っておくことも、併せてお勧めします。

    先にこちらからと思い、実行してみましたが、最初からエラーBreakしてしまいました。

    (アプリケーション画面が表示される前)

    こちらから調査していきたいと思います。

    貴重なお時間たくさんありがとうございました。

    ========

    ?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <avrf:logfile xmlns:avrf="Application Verifier">
    <avrf:logSession TimeStarted="2017-11-22 : 18:14:48" PID="4172" Version="2">
    <avrf:logEntry Time="2017-11-22 : 18:14:49" LayerName="Leak" StopCode="0x900" Severity="Error">
    <avrf:message>A heap allocation was leaked.</avrf:message>
    <avrf:parameter1>3212ed8 - Address of the leaked allocation. Run !heap -p -a &lt;address&gt; to get additional information about the allocation.</avrf:parameter1>
    <avrf:parameter2>1c35c7c - Address to the allocation stack trace. Run dps &lt;address&gt; to view the allocation stack.</avrf:parameter2>
    <avrf:parameter3>2e8afe0 - Address of the owner dll name. Run du &lt;address&gt; to read the dll name.</avrf:parameter3>
    <avrf:parameter4>54c20000 - Base of the owner dll. Run .reload &lt;dll_name&gt; = &lt;address&gt; to reload the owner dll. Use &apos;lm&apos; to get more information about the loaded and unloaded modules.</avrf:parameter4>
    <avrf:stackTrace>
    <avrf:trace>vfbasics!+5732af86 ( @ 0)</avrf:trace>
    <avrf:trace>vfbasics!+5732b93e ( @ 0)</avrf:trace>
    <avrf:trace>vfbasics!+57327041 ( @ 0)</avrf:trace>
    <avrf:trace>ntdll!RtlRemoveVectoredContinueHandler+142 ( @ 0)</avrf:trace>
    <avrf:trace>ntdll!LdrSetAppCompatDllRedirectionCallback+1c6ac ( @ 0)</avrf:trace>
    <avrf:trace>ntdll!LdrUnloadDll+15f ( @ 0)</avrf:trace>
    <avrf:trace>ntdll!LdrUnloadDll+3c ( @ 0)</avrf:trace>
    <avrf:trace>vfbasics!+57327636 ( @ 0)</avrf:trace>
    <avrf:trace>KERNELBASE!FreeLibrary+19 ( @ 0)</avrf:trace>
    <avrf:trace>mswstr10!+54d97380 ( @ 0)</avrf:trace>
    </avrf:stackTrace>
    </avrf:logEntry>

    2017年11月22日 9:40
  • > 先にこちらからと思い、実行してみましたが、
    > 最初からエラーBreakしてしまいました。
    説明するの忘れていましたが、Application Verifier は、デバッグ対象プロセス内に存在する全てのエラーを拾いまくります。
    つまり、プログラムの動作的な問題など表面的な現象として現れていないエラーも拾いまくるので、今回の AppCrash とは全く関係ないエラーも拾ってしまうことになります。
    なので、チェックする項目をできるだけ絞って検証する必要があります。
    (逆に絞り過ぎると「ザル」になってしまい、拾いたいエラーが検出できなくなってしまいますが。。。)
    提示されたログでは、なにかのモジュール (DLL, OCX, etc.) のアンロード時に、そのモジュール内でメモリ リークが検出された。。。ということらしいです。
    なんのモジュールなのかは、ライブデバッグなりダンプ解析なり、自分の好きなやり方で調べれば、すぐに特定できると思います。
    だた、今回の AppCrash はリークとはあまり関係無いような。。。。
    2017年11月22日 10:20
  • 本当にありがとうございます。

    いろいろなツールが初めてのものばかりなのでハードルはかなり高いですが一歩一歩進めてみます。

    まずライブデバッグとクラッシュログの違いから進めていこうかと思っています。

    クラッシュログ

    15 0013fabc 66051d33 08b67040 0013fce4 0013fc68 xx_10!01::Form_KeyDown+0x224 [01.frm @ 17195]

    16 0013fae0 66052034 00502772 0013fb9c 00000006 msvbvm60!IID_IVbaHost+0x236f3
    17 0013faf8 6605211a 08b672d0 0013fbdc 0013fb9c msvbvm60!IID_IVbaHost+0x239f4
    18 0013fbec 75f8884f 00000000 00000002 00000000 msvbvm60!IID_IVbaHost+0x23ada
    19 036705ac 6601a5a8 00000000 6610e460 00435f50 user32!CallHookWithSEH+0x51
    1a 036705b8 00435f50 00000000 00000000 00400000 msvbvm60!Zombie_Release+0xbb4f
    1b 036705bc 00000000 00000000 00400000 034820a4 xx_10!__vba+0x88

    ライブデバッグ(正常に動作するログ)

    10 0013fabc 66051d33 08998540 0013fce4 0013fc68 xx_10!01::Form_KeyDown+0x224 [01.frm @ 17195]
    11 0013fae0 66052034 00502772 0013fb9c 00000006 MSVBVM60!IID_IVbaHost+0x236f3
    12 0013faf8 6605211a 089987d0 0013fbdc 0013fb9c MSVBVM60!IID_IVbaHost+0x239f4
    13 0013fbec 755d884f 00000000 00000002 00000000 MSVBVM60!IID_IVbaHost+0x23ada
    14 0013fc24 6605fe39 0324e874 0000000f 0013fc44 USER32!CallHookWithSEH+0x51 (FPO: [Non-Fpo])
    15 0013fc70 6605fbe2 0324e874 00040534 00000100 MSVBVM60!IID_IVbaHost+0x317f9
    16 0013fca0 6605ce30 0324e874 0013fcdc 0013fce0 MSVBVM60!IID_IVbaHost+0x315a2
    17 0013fcd0 6605f97d 03269ec4 00040534 00000100 MSVBVM60!IID_IVbaHost+0x2e7f0
    18 0013fd2c 755d75b3 00040534 00000100 00000083 MSVBVM60!IID_IVbaHost+0x3133d
    19 0013fd58 755d77b8 6605f74e 00040534 00000100 USER32!_InternalCallWinProc+0x23
    1a 0013fdd8 755d79e6 00040534 00000100 00000083 USER32!UserCallWinProcCheckWow+0x110 (FPO: [SEH])
    1b 0013fe38 755e137b 0013fe80 6600a6c8 0013fe58 USER32!DispatchMessageWorker+0x1a1 (FPO: [Non-Fpo])
    1c 0013fe40 6600a6c8 0013fe58 ffffffff 033b1e54 USER32!DispatchMessageA+0x10 (FPO: [Non-Fpo])
    1d 0013fe80 6600a63f ffffffff 033b1e7c 033b0000 MSVBVM60!_vbaStrToAnsi+0x2f1
    1e 0013fec4 6600a51d 033b1f4c ffffffff 00000ebc MSVBVM60!_vbaStrToAnsi+0x268
    1f 0013fee0 6600a4e8 033b1e78 033b1f4c ffffffff MSVBVM60!_vbaStrToAnsi+0x146
    20 0013ff04 66003644 ffffffff 00435724 754d179b MSVBVM60!_vbaStrToAnsi+0x111

    2017年11月24日 1:43
  • > まずライブデバッグとクラッシュログの違いから
    > 進めていこうかと思っています。

    「クラッシュログ」と「ライブデバッグ」を、どーいう定義で使い分けているのかよくわからないのですが。。。
    「ライブデバッグ」が「正常に動作する」場合であるなら、デバッガに break-in することはないと思うのですが、だとしたらこのコールスタックはどーやって採取したのでしょうか?
    そもそも部分的なコール スタックを提示されても、コメントのしようがありません。
    コール スタックはそのスレッドでどのような関数コールが行われたのか示し、スタック フレームにはそれら個々の関数内でどのような変数にアクセスしたのかを示す手掛かりが残されています。
    つまりそれら情報をきちんと精査しないことには、問題の本質にたどり着くことはできないのです。
    今まで色々とダンプ ログを採取してもらったのも、問題の起きたスレッドでどのような処理が行われたのかをきちんと精査するためです。
    (精査したから、一番初めに採取した "dumpXX.log" で示されていたコール スタック情報は正しくなく、かつ ntdll!RtlImageNtHeader ルーチン内で例外が発生していることが分かった。。。ということです。)
    少なくとも私の知っているデバッグ手法は、そのような「泥臭い」方法なので、何かコマンドを実行すれば一発で問題点を検出してくれる。。。なんて夢ようなことはありません。
    (私がその「夢のような」方法を知らないだけかもしれませんけど。)

    「クラッシュログ」についてあえてコメントするなら。。。。
    フレーム 1a が "msvbvm60!Zombie_Release+0xbb4f" となっていることから、このスレッド内で例外が発生しゾンビ化したと推測されます。
    例外が発生したなら、例外ハンドラによりその時のフレーム情報が残されているかも。
    とりあえず下記コマンドを実行してみては?
    ----------------------------------------
    <実行するコマンド>
    .ecxr
    kvn
    ----------------------------------------
    2017年11月24日 3:10
  • すみません、また余計なお手間をおかけいたしました。


    2017年11月24日 3:45