7

I am using the QFileDialog::getOpenFileName function to get a file to open. However, on a client's computer running Windows 7 this either displays a corrupted open file dialog as shown in the screenshot, or crashes the entire application.

Corrupted Dialog

The code I use to open the file dialog is:

void MainWindow::on_action_triggered() {
    auto filename = QFileDialog::getSaveFileName(this, "Generate Report", "", "CSV files (*.csv)");

    if (filename.isEmpty()) {
        return;
    }

    // Do operations on filename...
}

I am using Qt 5.5 with Visual Studio 2013.

ajshort
  • 3,684
  • 5
  • 29
  • 43
  • Doeas it happen with `getOpenFileName`, `getSaveFileName` or both? – Mailerdaimon Oct 08 '15 at 06:17
  • 1
    Try in debug build, probably you miss some dlls in release. – Jerry Oct 08 '15 at 06:27
  • @Mailerdaimon it happens for both. – ajshort Oct 08 '15 at 09:24
  • Have you tried it on your PC as standalone app (not started from Visual Studio)? – Mailerdaimon Oct 08 '15 at 09:45
  • @Mailerdaimon it works fine on my computer, this is as a standalone distributed application on a client's computer. I can't replicate it myself unfortunately. – ajshort Oct 08 '15 at 11:41
  • 1
    I know nothing about Qt, but in Win32 you need to call CoInitialize() or OleInitialize() to use the common file dialogs. Perhaps there's an init method that's been missed? – Jonathan Potter Oct 27 '15 at 10:59
  • Like @JonathanPotter, I get the feeling it's not Qt-specific. Have a look at this forum (http://superuser.com/questions/378296/windows-7-save-dialog-hang-any-solutions). There's no way to be sure, but a freeze due to some shell extension that would be installed only on this specific client's PC seems to fit the picture. – Daniel Strul Oct 27 '15 at 20:14
  • @DanielStrul Thanks for the interesting idea! I will have access to the client's computer in a few weeks and will try and see if this is the issue. Unfortunately I probably can't find until then. – ajshort Oct 27 '15 at 21:47
  • @ajshort 'hope this helps! For the record, here is the google search I used to find this possible solution (https://www.google.com/search?q=openfiledialog+hangs&tbm=isch) -> it allows for searching all images tagged "openfiledialog hangs". Whenever there is a screen cap that looks exactly like yours, it's a potential candidate. Good luck! – Daniel Strul Oct 27 '15 at 22:01
  • 1
    Just a guess - but can you try **initialising the start-directory** to - say: C:? The reason I'm asking is twofold - it might be Windows trying to resume in "a previous location" that is now invalid, or it might be a Qt-level bug that handles WIN32/WIN64 incorrectly. Please do log a bug with Qt if you find that it works :) – Fox Oct 28 '15 at 09:01
  • Consider: http://stackoverflow.com/questions/25270513/qfiledialoggetopenfilename-crashes-when-debugging-apparently-caused-by-projec – ManuelH Nov 02 '15 at 15:58

3 Answers3

6

The issue in this particular case ended up being an incompatibility between Qt and the Dell Backup and Recovery software installed on the client's computer, which included an incompatible shell extension. The solution I used was to remove the backup and recovery software, but it sounds like namespacing Qt is also an alternative. More information is available in QTBUG-41416.

ajshort
  • 3,684
  • 5
  • 29
  • 43
5

I'm guessing that there is a problem with directory. This empty string provided as path might be problematic. Try fix this this way:

auto filename = QFileDialog::getSaveFileName(this, 
                                             tr("Generate Report"),
                                             QString(),
                                             tr("CSV files (*.csv)"));
// or this way
auto filename = QFileDialog::getSaveFileName(this,
                                             tr("Generate Report"),
                                             QDir::home().absolutePath(),
                                             tr("CSV files (*.csv)"));
Marek R
  • 32,568
  • 6
  • 55
  • 140
  • Cheers! I have sent the client an application with both of these to test. If it isn't this I guess it's probably a dodgy shell extension as some of the comments suggested. – ajshort Nov 03 '15 at 01:41
  • No luck unfortunately - I tried variants with no argument, a default-construct QString, and an existing directory for the same result. Thanks though! – ajshort Nov 03 '15 at 01:49
  • can you provide a crash call stack? It is easiest if you build Qt yourself. – Marek R Nov 03 '15 at 11:40
2

The root of your problem seems to be memory corruption. To find it, install Microsoft Application Verifier and configure your app with Basics\Heaps. You can do it on your own computer, even if the original problem didn't reproduce. After that, try to reproduce the problem, and I guess you will find your memory corruption.

Update
Now that the problem didn't reproduce on your machine and you say the dialog is hung, I suggest the following additional steps (you can do everything yourself in a TeamViewer session to make it easier)

  1. Enable Application Verifier on customer's machine for your EXE. As a side effect, that enables heap tracing.
  2. Capture a (series) of dumps during the hung. Have at least one full dump among the series. You can for example do it with SysInternals Process Explorer. Analyzing them later, you would be able to see what the application is doing. Don't forget to generate and save PDB files (debug information) for your EXE (although I think the hung would be outside your exe).
Codeguard
  • 7,787
  • 2
  • 38
  • 41
  • Gave it a shot, no luck unfortunately. – ajshort Nov 02 '15 at 02:18
  • I suggest that you ask your customer for precise actions he's performing. For memory corruption, a buffer overflow is quite typical. That is, something can be bigger then you expected. – Codeguard Nov 02 '15 at 07:24
  • I sent the customer a minimal program which only opened a file dialog (nothing else), and it still exhibited the problem. – ajshort Nov 02 '15 at 09:23
  • I think I'd vouch for a bad shell extension on customer's machine, then. If you're still interested in finding the root of that problem, I can provide advanced troubleshooting steps, involving capturing a minidump with heap tracing. – Codeguard Nov 02 '15 at 19:00
  • Cheers! I've actually integrated a crash reporter into the application which sends me a minidump. Unfortunately the dialog just seems to hang and hasn't crashed recently though :( – ajshort Nov 02 '15 at 21:04
  • Did you solve the issue? If yes, please describe it for future readers. – Codeguard Nov 18 '15 at 08:42
  • Unfortunately not yet. I'm visiting the client's site next week so if I can fix it will post details. – ajshort Nov 18 '15 at 08:56