QFileDialog::getOpenFileName causing program to crash

crackysk

Thank you for reply. I even tried QFileIconProvider::DontUseCustomDirectoryIcons at some point, but didn't cross my mind that's not doing anything useful.

I tried providing icon provider directly to static QFileDialog for save/open file that I was using, but it made no difference. Also, creating custom FileIconProvider and providing it to instance of QFileDialog created in app made no difference (also creating custom QFileDialog class).
So, I basically moved to same thing as you did. I've written my own dialog that's doing same thing as static one I was using before.
Now, I have treeView and listView next to each other, both of them provided with different QFileSystemModel (different when it comes to filter) and provided custom QFileIconProvider class that has icon() overridden. And really, crashes are gone!

Honestly, I don't even mind having same file icon for each file type. For purposes I need it for, this is more than enough. But, if someone needs it, probably can even do similar thing like you did for a role and look for a specific QFileInfo that makes a mess and for all others use just default constructor for QIcon as you did.

All that's left to do is handling cosmetics in order to make this new QDialog as close as possible to the one.

Vsevolod7

Same problem.

? Offline

I copy your codes and run it on win11 successfully. I used Qt5.13 and the compiler 'MingGW 64bit'. Add I tried the compiler 'MSVC2015', it is all right too. I think our developing environment are similar to each other.

az1699

Same issue here. I've a test application made few months ago that always worked. I fixed by working around using DontUseNativeDialog.

If I run the same application, same build, on windows sand box it works perfectlly. Dont know why, windows sand box should have the same windows system update as my system

az1699

I also tried this, don't why but after istancing QFileDialog with QFileDialog::DontUseNativeDialog I can start using QFileDialog in the previous way. I tested this simple example and works.

    static bool first_run = true;
    if (first_run) {
        CmdOpenFile(QFileDialog::getOpenFileName(0, "Open some file", QString(), QObject::tr("All files (*.*)"), nullptr, QFileDialog::DontUseNativeDialog));
        first_run = false;
    } else {
        CmdOpenFile(QFileDialog::getOpenFileName(0, "Open some file", QString(), QObject::tr("All files (*.*)")));
    }

Violet Giraffe

I can't speak for every case in particular, but these symptoms are very typical for a misbehaving shell / Explorer extension, and not related to Qt, most likely.

I've seen some projects (for example - Firefox) maintain a list of known faulty DLLs and use LoadLibrary hooks to prevent those DLLs from loading.

sir_clive

I'd like to add my experience with this issue.

I pulled my hair out over a very similar (probably the same?) problem lately, and it turned out that AVAST and AVG (practically the same product) are causing this problem in my case. These programs must be uninstalled (not deactivated, but completely uninstalled) for my program to start working again.

My program was working on multiple versions of Windows for years already, with no issues whatsoever. The problems started in February this year (2023), and affect every single "file dialog" instance my program tries to open.

The tip with not using native dialog did not help in my case. Also VMWare based Windows installations are not affected, only the "bare metal" ones. Also, 5.x and 6.x QT versions are both crashing if AVAST or AVG are installed.

I'm surprised not more QT programs are affected, this is the best thread I found so far.

az1699

@sir_clive I've Avast antivurs on my computer, i tested in an other without avast and works :(

So maybe reporting this issue the could fix it

VirtualFloat

Running into the same issue here on some corporate windows 11 machines. So in 2025 it is still causing issues.

Violet Giraffe

@VirtualFloat
Does the crash occur in a Qt .dll, or inside a foreign dll injected by some security software? The latter is, unfortunately, not uncommon.