wxMessageDialogs causing access violation exceptions in x64 configurations

[Karlovsky120]

Disclaimer: This has been asked on stackoverflow:
https://stackoverflow.com/questions/475 ... -exception

I'm using wxWidgets 3.0.3 and have set up the project using instructions (Visual studio 2017) provided here:
https://wiki.wxwidgets.org/Microsoft_Vi ... B%2B_Guide

I compiled the binaries myself using the same IDE and have not changed any of the settings.


I have following code:
(Note that I've ran a similar snippet in the same project while using wxFileDialog and it worked in both x64 and x86 configurations. So I must've set the library properly at least to some degree.)

Main.h

Code: Select all

#pragma once

#include <wx\wxwidgets.h>

class Main : public wxApp {
public:
    virtual bool OnInit();
};

main.cpp

Code: Select all

#include "Main.h"
bool Main::OnInit() {  
    wxMessageDialog *test= new wxMessageDialog(nullptr, wxT("Test"));
    test->ShowModal();
    return true;
}

wxIMPLEMENT_APP(Main);

If I run this in a x86 config, it runs without a hitch. However, when I switch it to a x64 config, I get a Access Violation reading location 0x00000000BEBC0000 exception at line 594 of msgdlg.cpp:

Code: Select all

int wxMessageDialog::ShowModal()
{
    WX_HOOK_MODAL_DIALOG();

#ifdef wxHAS_MSW_TASKDIALOG
    if ( HasNativeTaskDialog() )
    {
        TaskDialogIndirect_t taskDialogIndirect = GetTaskDialogIndirectFunc();
        wxCHECK_MSG( taskDialogIndirect, wxID_CANCEL, wxS("no task dialog?") );

        WinStruct<TASKDIALOGCONFIG> tdc;
        wxMSWTaskDialogConfig wxTdc( *this );
        wxTdc.MSWCommonTaskDialogInit( tdc );

        int msAns;
--HERE->HRESULT hr = taskDialogIndirect( &tdc, &msAns, NULL, NULL );
        if ( FAILED(hr) )
        {
            wxLogApiError( "TaskDialogIndirect", hr );
            return wxID_CANCEL;
        }

        // In case only an "OK" button was specified we actually created a
        // "Cancel" button (see comment in MSWCommonTaskDialogInit). This
        // results in msAns being IDCANCEL while we want IDOK (just like
        // how the native MessageBox function does with only an "OK" button).
        if ( (msAns == IDCANCEL)
            && !(GetMessageDialogStyle() & (wxYES_NO|wxCANCEL)) )
        {
            msAns = IDOK;
        }

        return MSWTranslateReturnCode( msAns );
    }
#endif // wxHAS_MSW_TASKDIALOG

    return ShowMessageBox();
}

I've set a breakpoint and it fails when entering the function. Since msAns has just been declared, I doubt that's the problem, so the only possible culprit left is tdc.

Does any of this make any sense?
Is it a bug within the library?
Did I set something wrong?
How do I make it work?

[doublemax]

I'm using wxWidgets 3.0.3 and have set up the project using instructions (Visual studio 2017) provided here:

So you built a new VS project from scratch?

Try again by putting your code in the "minimal" sample that comes with wxWidgets. I'm almost certain it won't crash there.

BTW: Your code is leaking the wxMessageDialog pointer.

[Karlovsky120]

I just tried it, it doesn't work when I paste it into the sample project.

Could I have somehow compiled the library incorrectly?

What settings would affect x64 configs, but not x86 and vice versa?

[doublemax]

I just tried it, it doesn't work when I paste it into the sample project.

Did you build both the libraries and the sample with the original make or project files?

[doublemax]

Just tested with VS2013, x64-build of wxWidgets and the sample through the original solution files. No problem.

[Karlovsky120]

Okay, so let's try this, I'll tell you what I did exactly:


I've noticed there is a 3.1.0 version, so I decided to switch to that, removing the 3.0.3 version (deleting anything related in my project in lib and include folders).
I've downloaded the source code from here:

https://github.com/wxWidgets/wxWidgets/ ... tag/v3.1.0 (Source code (zip))

I've then opened and extracted the whole folder, went into build\msw\ and opened wx_vc14.sln with visual studio 2017. I upgraded all the projects to v141 and 10.0.16299.0. I haven't changed any settings in the setup.h
I've then went to the batch build and have built all the projects in all the configurations.

Result: ========== Build: 192 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

I've then copied the lib\vc_lib and lib\vc_x64_lib into my projects lib folder as well as copied include contents into my include folder (I've deleted what was previously there, the 3.0.3 stuff).

I then started up my project and compiled all four configurations (Release/Debug|x86/x64).

I ran the program and both x64 failed as I described in the first post, while the x86 versions ran fine.

Now, here are my bolded project settings for Debug x64:

Code: Select all

Windows SDK Version: 10.0.16299.0
Platform Toolset: Visual Studio 2017 (v141)
Character set: Use Unicode Character set
Additional Include Directories: $(ProjectDir)include;$(ProjectDir)include\msvc;%(AdditionalIncludeDirectories)
Warning Level: Level3 (\/W3)
SDL checks: Yes (/sdl)
Optimization: Disabled (/Od)
Preprocessor Definitions: WIN32;_WINDOWS;WINVER=0x0500;__WXMSW__;wxUSE_GUI=1;_DEBUG;__WXDEBUG__;_CRT_SECURE_NO_DEPRECATE;_CRT_NONSTDC_NO_DEPRECATE;%(PreprocessorDefinitions) (I was getting issues with WINVER=0x0400)
Runtime Library: Multi-threaded Debug DLL
Additional Library Directories: $(ProjectDir)lib\vc_x64_lib
Additional Dependencies: comctl32.lib;rpcrt4.lib;winmm.lib;advapi32.lib;wsock32.lib;wxmsw31ud_core.lib;wxbase31ud.lib;wxpngd.lib;wxzlibd.lib;wxjpegd.lib;wxtiffd.lib;%(AdditionalDependencies)
SubSystem: Windows (/SUBSYSTEM:WINDOWS)

Note that the Additional Library Directory is the ONLY setting that's different between the Debug x86 version that works and Debug x64 that doesn't.

Also note that I want to use .lib files and statically link them, opposed to using the dlls (which is why I'm compiling the library myself).

I want to make the whole project and solution not dependable on the environment it's in, so instead of placing wxWidgets files somewhere on my PC and adding them to the PATH variable, I've just placed the appropriate components in lib and include directories of my project.

I've tried to run the internat project from the samples folder, and it works as it is. However, if I substitute all the code in internat.cpp with:

Code: Select all

#include "wx/wxprec.h"

#ifdef __BORLANDC__
#pragma hdrstop
#endif

#ifndef WX_PRECOMP
    #include "wx/wx.h"
#endif

class Main : public wxApp {
public:
	virtual bool OnInit();
};

bool Main::OnInit() {
	wxMessageDialog *test = new wxMessageDialog(nullptr, wxT("Test"));
	test->ShowModal();
	return true;
}

wxIMPLEMENT_APP(Main);

It fails just like my own project does, only the x64 builds.

Given that the sample project seems to be failing as well, my guess is that something went wrong when compiling the x64 library components, but not wrong enough to throw an error. Or might it be some kind of incompatibility with VS2017? Or is some setting set wrong?

I'm at my wits end here. I really don't know what to do next.

Can you figure out what's wrong, with all this info?

[doublemax]

Can you figure out what's wrong, with all this info?

No.

While you're researching this, stick to the wx samples. All that stuff you do with your project just adds a huge pile of potential error sources.

Right now, my guess is that it's VS2017 or the new toolset that causes the problem. Do you have access to a "clean" machine where you can install VS2015 and test with that one? (Don't install multiple VS version on the same machine, that's a recipe for disaster - as you probably know).

Also, can you take the original "minimal" sample and put the code with the wxMessageDialog into MyFrame::OnAbout() and check if the code still crashes there?

[Karlovsky120]

Oh wow, if I put the code in the OnAbout, it works with no issues in any configuration. It seems to break only if I try to initialize the wxMessageDialog before any other component or something like that?

I don't have access to a clean machine to install VS2015 on, sorry.

But given all the data, if it works for you in all cases, and doesn't work for me in VS2017/v141 and when initializing wxMessageDialog before anything else, it really might be a compatibility issue between wxWidgets and VS2017/v141 for that specific case.

Also, my project is no longer relevant since the same code crashes in the sample project that must be configured properly. I shouldn't have really included any info about it once I figured that out.


//Offtopic part
But regarding my issue, what I'm trying to do in my project is inform the user that he needs certain files for the program to run with wxMessageDialog, then open wxFileDialog for the user to locate them and then if all goes well open the main wxFrame of the program (which will after that always be open), otherwise display another wxMessageDialog informing the user that the program will now exit.

Am I doing this wrong?

I might be able to circumvent the problem by doing it some other way.

[Greg Smith]

If turning off optimisation around the point of failure fixes the problem it may well be a code generation problem. If it does, you should report the problem to Microsoft, especially if you can reduce the problem to a relatively small example. Use the Help->Send Feedback->Report a problem option. If you can generate a small project that generates the problem and send it to them you will find them responsive.

[doublemax]

I finally had some time to try this myself, but i couldn't reproduce the issue in any of the samples.

Windows 10 Pro X64
VS 2017 Community (Version 15.5.2)
wxWidgets, today's version from GIT
Runtime V141
SDK 10.0.16299.0
X64 Build

[catalin]

I've just seen this and the only relevant link found for it by Google was this thread

To reproduce it in minimal sample, add wxMessageBox("some message"); just before frame->Show(true);, build Debug mode, and run the sample under the debugger.
Win 10, x64, VS 2017, 10.0.16299.0, wxW 3.1.1rc

Strage things:

• TaskDialogIndirect throws that exception when it receives a null pTaskConfig->hwndParent, although the latter is explicitly allowed to be null;
• hitting Continue several times in the debugger will eventually go on, TaskDialogIndirect will return S_OK and everything will continue normally; the only trace after that is the output message

  Code: Select all

  Exception thrown at 0x00007FF953A7FB46 (ntdll.dll) in minimal.exe: 0xC0000005: Access violation reading location 0x00000000256B0000.

• nothing unusual is noticeable when the app is run outside the debugger or in Release mode.