Question

我们有一个C应用程序，它使用GetOpenFileName公共对话框让用户选择一个文件。我们一直在Windows2008R2上崩溃。我发现如果我们在我们的应用程序上放置DEP异常，则崩溃停止

但是，我无法弄清楚我们做错了什么或者我们可以做些什么来阻止崩溃。我已将代码放在下面。

typedef struct {
    OPENFILENAME    ofn;
    COUNT       nInternal;
    COUNT       nExternal;
    char        szDirName[_MAX_DIR];
    char        szFile[_MAX_PATH];
    char        szFileTitle[_MAX_PATH];
    char        szFilter[128];
} OPENFILENAMEINFO;

typedef OPENFILENAMEINFO FAR *LPOPENFILENAMEINFO;


LPOPENFILENAMEINFO RequestFileNameEx(HWND hDlg, LPSTR lpExt, BOOL bSave, LPSTR lpInit)
{

    LPOPENFILENAMEINFO lpFileNameInfo;
    int i;
    DWORD   dwError;
    DWORD   dwSize;
    LPSTR   lpDir;
    LPSTR   lpDrive;

    lpFileNameInfo = (LPOPENFILENAMEINFO)mballc(1,sizeof(OPENFILENAMEINFO));
    strcpy(lpFileNameInfo->szFilter,lpExt);

    for (i=0; lpFileNameInfo->szFilter[i] != '\0'; i++) {
        if (lpFileNameInfo->szFilter[i] == '|')
            lpFileNameInfo->szFilter[i] = '\0';
    }

    memset(&lpFileNameInfo->ofn, 0, sizeof(OPENFILENAME));

    lpFileNameInfo->ofn.lStructSize = sizeof(OPENFILENAME);
    lpFileNameInfo->ofn.hwndOwner       = hDlg;
    lpFileNameInfo->ofn.lpstrFilter = lpFileNameInfo->szFilter;
    lpFileNameInfo->ofn.nFilterIndex    = 1;
    lpFileNameInfo->ofn.lpstrFile       = lpFileNameInfo->szFile;
    lpFileNameInfo->ofn.nMaxFile        = sizeof(lpFileNameInfo->szFile);
    lpFileNameInfo->ofn.lpstrFileTitle  = lpFileNameInfo->szFileTitle;
    lpFileNameInfo->ofn.nMaxFileTitle   = sizeof(lpFileNameInfo->szFileTitle);

    lpFileNameInfo->ofn.lpstrInitialDir = _getcwd(lpFileNameInfo->szDirName, _MAX_DIR);

    if (bSave) {
        lpFileNameInfo->ofn.Flags           = OFN_SHOWHELP | OFN_PATHMUSTEXIST | OFN_OVERWRITEPROMPT | OFN_NOCHANGEDIR;
        dwError = GetSaveFileName(&lpFileNameInfo->ofn);
    } else {
        lpFileNameInfo->ofn.Flags           = OFN_SHOWHELP | OFN_PATHMUSTEXIST | (bDir==FALSE?OFN_FILEMUSTEXIST:0) | OFN_NOCHANGEDIR;
        dwError = GetOpenFileName(&lpFileNameInfo->ofn);
    }

    if (!dwError) {
        dwError = CommDlgExtendedError();
        if (dwError)
            ResourceHandleError(GETOPENFAIL, dwError);
        mbfree(lpFileNameInfo);
        return(NULL);
    }


    return(lpFileNameInfo);
}

崩溃转储堆栈跟踪看起来像

0023:73E61FFF (0x080D7974 0x080D7970 0x078B62F0 0x00000000) msxml6.dll
0023:73E68165 (0x080D7970 0x080D78F0 0x078B62F0 0x080D78F0) msxml6.dll, DllCanUnloadNow()+22084 byte(s)
0023:73E67D08 (0x078B62F0 0x080D7970 0x00000000 0x080D78F0) msxml6.dll, DllCanUnloadNow()+20967 byte(s)
0023:73E6827A (0x080D78F0 0x080D7970 0x080D7950 0x59E489BA) msxml6.dll, DllCanUnloadNow()+22361 byte(s)
0023:73E68241 (0x080D7970 0x080D7950 0x59E489BA 0x00000000) msxml6.dll, DllCanUnloadNow()+22304 byte(s)
0023:73E69DDF (0x00000000 0x080D7950 0x00000000 0x0762FAE0) msxml6.dll, DllCanUnloadNow()+29374 byte(s)
0023:73E6BF9F (0x080D7970 0x080D7950 0x71932915 0x078B5E90) msxml6.dll, DllGetClassObject()+5125 byte(s)
0023:73E6BF83 (0x73E81B38 0x080D39C0 0x080D39C0 0x080D3980) msxml6.dll, DllGetClassObject()+5097 byte(s)
0023:73E6C318 (0x71932881 0x06148CB8 0x06148CB8 0x00000000) msxml6.dll, DllGetClassObject()+6014 byte(s)
0023:73E6CD18 (0x720B35A0 0x0762FBD8 0x06148CB8 0x0762FD68) msxml6.dll, DllGetClassObject()+8574 byte(s)
0023:73E78671 (0x720B35A0 0x0762FBD8 0x0762FD68 0x00000000) msxml6.dll, DllGetClassObject()+56023 byte(s)
0023:73E6AAE5 (0x73E6AC28 0x00000000 0x720B35A0 0x0762FBD8) msxml6.dll, DllCanUnloadNow()+32708 byte(s)
0023:74B0A0E1 (0x00000000 0x00000000 0x00000000 0x00000001) ole32.dll, CoCreateInstanceEx()+0915 byte(s)
0023:74B09FA1 (0x720B3614 0x00000000 0x00000017 0x00000000) ole32.dll, CoCreateInstanceEx()+0595 byte(s)
0023:74B09E25 (0x720B3614 0x00000000 0x00000017 0x00000000) ole32.dll, CoCreateInstanceEx()+0215 byte(s)
0023:74B09D86 (0x720B3614 0x00000000 0x00000017 0x00000000) ole32.dll, CoCreateInstanceEx()+0056 byte(s)
0023:74B09D3F (0x720B3614 0x00000000 0x00000017 0x720B35A0) ole32.dll, CoCreateInstance()+0052 byte(s)
0023:720B352B (0x0553A7C0 0x00000000 0x0070E2DC 0x0070E288) FunDisc.dll
0023:720B9470 (0x0553A7C0 0x00000000 0x00000001 0x00000001) FunDisc.dll, DllGetClassObject()+21871 byte(s)
0023:720C3B69 (0x00000001 0x0070E288 0x8007000E 0x00000000) FunDisc.dll, DllUnregisterServer()+20504 byte(s)
0023:720B75AA (0x73751590 0x00000000 0x00000001 0x00000000) FunDisc.dll, DllGetClassObject()+13993 byte(s)
0023:720B1CE9 (0x73751590 0x00000000 0x00000001 0x055874F8) FunDisc.dll
0023:720B1C39 (0x00709310 0x73751590 0x00000000 0x00000001) FunDisc.dll
0023:73752F84 (0x055E2F28 0x00709310 0x73751590 0x00000000) NetworkItemFactory.dll
0023:737530A5 (0x055E2F28 0x0762FF88 0x763643C0 0x055E2F28) NetworkItemFactory.dll
0023:73753144 (0x055E2F28 0x00000000 0x00000000 0x03EDFB9C) NetworkItemFactory.dll
0023:763643C0 (0x03EDFB9C 0x0762FFD4 0x77029EF2 0x03EDFB9C) SHLWAPI.dll, IUnknown_QueryService()+0346 byte(s)
0023:74C9339A (0x03EDFB9C 0x13BB74FB 0x00000000 0x00000000) kernel32.dll, BaseThreadInitThunk()+0018 byte(s)
0023:77029EF2 (0x763642ED 0x03EDFB9C 0xFFFFFFFF 0x770B736F) ntdll.dll, RtlInitializeExceptionChain()+0099 byte(s)
0023:77029EC5 (0x00000000 0x00000000 0x00000000 0x00000000) ntdll.dll, RtlInitializeExceptionChain()+0054 byte(s)

Answer 1

我遇到了同样的问题，并在Synastry上找到了可能的解决方案

http://social.msdn.microsoft.com/Forums/en-US/vcmfcatl/thread/5037519a-78e2-42f4-94cd-bbe88e0f16d6/

我们所有遭遇此问题的人都在函数'CoUninitialize'中有一个调用堆栈。 COM的工作线程结束时自动调用此函数。此工作线程不是由用户直接创建的，但是当调用某个使用COM库的函数时，它会创建它（或它们）。而wagscallion和我通常称之为'GetOpenFileName'函数。我猜GSansoucie也称一些COM自动化功能。

结束工作线程并被称为“CoUninitialize”是COM库的合法和正常操作。那不是原因。我们遇到的例外是由于COM Server在使用时未初始化而导致的。但是除了一件事之外，我们（或者至少是我的）代码也是合法且恰当的。我的代码中从未调用过'CoInitialize'或'CoInitializeEx'功能。

COM库有一个内部计数（类似于引用计数器），它通过调用CoInitialize或CoInitializeEx递增，并通过调用CoUninitialize递减。但我没有调用任何初始化函数。虽然我没有调用它，但是GetOpenFileName函数在GetOpenFileName的实现中为它的工作线程调用它。在函数返回后，工作线程暂时等待另一个COM作业。这就是GetOpenFileName函数返回时不会立即发生异常的原因。但是工作线程决定自己结束，他们调用CoUninitialize，现在COM库服务器的内部计数为0，CoUninitialize释放内存中的所有资源。

但是在GetOpenFileName函数返回之后，一些资源应该保留在内存中（我不能确定这一点，但如果这个假设不成立，我们永远不会遇到异常）。为了保持它们不被释放，我们需要在程序初始化时调用CoInitialize或CoInitializeEx（MSDN建议稍后）。此外，我们需要在程序结束前调用CoUninitialize。

简而言之，我们需要在程序开始时调用'CoInitialize'或'CoInitializeEx'，并在程序结束时调用'CoUninitialize'。但是MSDN没有为GetOpenFileName或使用COM库的任何其他函数描述这一点。： - （

在我的情况下，通过调用初始化程序和uninitializer，问题就消失了，现在每个人都运行良好。看一看并将其应用于您的代码。如果您知道导致此例外的另一个原因，请告诉我们。： - ）

感谢您的阅读。

对于我自己来说，这不是解决方案，而是提示在哪里查看。我在我的多线程应用程序中使用了CoInitialize，它在内部使用COINIT_APARTMENTTHREADED调用CoInitializeEx。我现在将调用从CoInitialize（NULL）更改为CoInitializeEx（NULL，COINIT_MULTITHREADED），我的问题似乎消失了。

C应用程序使用GetOpenFileName崩溃。 DEP停止崩溃

1 个答案: