Click here to Skip to main content
15,867,568 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Following up on my previous question (Is getopenfilenname interacting badly with VS now?[^]), I have reproduced the issue with just about the simplest window possible. In VS 2019 I create a minimal Windows project and only add a 'commdlg.h' include and the OpenFileDialog code to the default template code VS generates. When I execute it, I get the same exceptions thrown on the OpenFileDialog call as I previously obtained.

Any ideas as to what could cause this issue? I believe this rules out any memory overruns on my part, because it's all MS's default code except for the OpenFileDialog stuff.

The exception text: Exception thrown at 0x77E7436F (ntdll.dll) in WindowsProject1.exe: 0xC0000005: Access violation reading location 0xFFFFFFFC.

Like before, I can continue the execution and don't see any immediate problems. I'm leaning towards the only solution being a Windows reinstallation, but I pray I'm overlooking something obvious.

Thanks,
David


C++
//Add following include:
#include "commdlg.h"

//WinMain NOW LOOKS LIKE:

int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPWSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: Place code here.

       //THE FOLLOWING IS ONLY ADDITION TO VS'S AUTO-GENERATED CODE:
       TCHAR filePtrC[MAX_PATH] = { 0 };
       OPENFILENAME tofn = { 0 };
       tofn.lStructSize = sizeof(tofn);
       tofn.hwndOwner = NULL;
       tofn.lpstrFile = filePtrC;
       tofn.nMaxFile = MAX_PATH;
       tofn.lpstrFilter = L"All\0*.*\0Text\0*.TXT\0";
       tofn.nFilterIndex = 1;
       tofn.lpstrFileTitle = NULL;
       tofn.nMaxFileTitle = 0;
       tofn.lpstrInitialDir = NULL;
       tofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
       GetOpenFileName(&tofn);  //Get two exceptions thrown here.

    // Initialize global strings
    LoadStringW(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadStringW(hInstance, IDC_WINDOWSPROJECT1, szWindowClass, MAX_LOADSTRING);
    MyRegisterClass(hInstance);

    // Perform application initialization:
    if (!InitInstance (hInstance, nCmdShow))
    {
        return FALSE;
    }

    HACCEL hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WINDOWSPROJECT1));

    MSG msg;

    // Main message loop:
    while (GetMessage(&msg, nullptr, 0, 0))
    {
        if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }

    return (int) msg.wParam;
}


What I have tried:

A lot more cussing. Creating the simplest solution in the world to replicate the issue. Followed by a big wtf when it failed.
Posted
Comments
Stefan_Lang 4-Feb-20 2:29am    
What char type have you declared in your project settings? I'm asking because you are passing a wchar_t* literal to the filter parameter. If it expects a char* instead .... anything can happen.
Richard MacCutchan 4-Feb-20 4:57am    
I just tried the same thing in VS2017 and it works fine, so it must be version specific (sorry don't have 2019 installed). You could try putting a breakpoint at the OPENFILENAME line and stepping through the code, checking all the variables, to see if you can spot any anomalies.

Also, for completeness, you should change that TCHAR to WCHAR since your program is obviously Unicode specific.
David O'Neil 4-Feb-20 5:51am    
Thank you guys! I changed it to WCHAR and nothing nothing changes in the running. (Yes, it is Unicode.) I'll install VS on my other computer and see if it craps out there. The assembly view shows the following, with the cursor at the last line when the exception occurs, but I've never mastered assembly:

77B7432F  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74335  mov         dword ptr [edx],ecx  
77B74337  mov         ebx,dword ptr [ebp+8]  
77B7433A  test        ebx,0FFFFFFFCh  
77B74340  jne         _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74346  mov         eax,dword ptr [ebp+0Ch]  
77B74349  test        eax,eax  
77B7434B  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B74351  cmp         eax,0FFFFFFFFh  
77B74354  je          _RtlCaptureStackContext@12+5D7Ch (77BCEE9Ch)  
77B7435A  mov         edi,dword ptr [ebp+14h]  
77B7435D  test        bl,1  
77B74360  je          RtlImageNtHeaderEx+0DDh (77B743CDh)  
77B74362  xor         bl,bl  
77B74364  mov         esi,dword ptr [ebp+10h]  
77B74367  mov         dword ptr [ebp-4],ecx  
77B7436A  mov         edx,5A4Dh  
77B7436F  cmp         word ptr [eax],dx  
David O'Neil 4-Feb-20 6:06am    
After downloading from the MS symbol servers, the call stack is at ntdll.dll!RtlImageNtHeaderEx(), if that is a useful clue.
David O'Neil 4-Feb-20 6:17am    
And the disassembly view. The cursor is at the last cmp line:

006B1DED  mov         dword ptr [ebp-244h],0  
       tofn.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
006B1DF7  mov         dword ptr [ebp-23Ch],1800h  
       GetOpenFileName(&tofn);
006B1E01  mov         esi,esp  
006B1E03  lea         eax,[tofn]  
006B1E09  push        eax  
006B1E0A  call        dword ptr [__imp__GetOpenFileNameW@4 (06BB000h)]  
006B1E10  cmp         esi,esp  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900