0

When we trigger File>>Open from within our application, we open a Windows Explorer file dialog... standard for most of the world's Windows applications. This means that any shell extension DLLs that a user has installed now get loaded as part of our EXE. We believe that some shell extension is mucking with memory in a way that makes our EXE crash. We would like to somehow open the file dialog without all the shell extensions running. Is there a way to do that? None of the options indicate this ability through the API. https://learn.microsoft.com/en-us/windows/win32/api/shobjidl_core/ne-shobjidl_core-_fileopendialogoptions

C++ or C# solutions welcome.

Inquisitor
  • 49
  • 8
  • Have you tested that theory by creating a simple app and adding file open there? That might be easier to debug. Or is this only on customer PCs not yours? I can't answer the question, but one last resort would be to make your own using the directory/file listing APIs. – Dave S Apr 11 '23 at 19:49
  • @DaveS We are pretty sure about our theory. It's hard to get a memory overflow to hit something easy to test, but we're working on it. Writing our own file dialog is an option on the table, but, obviously, that's a fair amount of UI work to equate to something MS has spent so much time polishing. Getting the basics is easy but not as nice for our users. Thus this question. – Inquisitor Apr 11 '23 at 19:51
  • 1
    An extension viewer/disabler might help to narrow it down - ShellExview - http://www.nirsoft.net/utils/shexview.html – Dave S Apr 11 '23 at 19:54
  • Just fix your machine and get rid of the bad extensions. Use SysInternals' AutoRuns and start by disabling the extensions that don't have a Microsoft copyright. – Hans Passant Apr 11 '23 at 19:58
  • @HansPassant I wish, but it is not for me to limit what my users install on their machines! I assure you, we're exploring many different options. I asked this question to explore this specific option, not to say that nothing else was on the table. – Inquisitor Apr 11 '23 at 20:34
  • 1
    It is a problem that's (almost) exclusive to programmer's machines. They tend to install too much crap and know too much from the debugger. The end-user is rarely affected, IT staff limits what they can install and simply re-image the machine when it starts to misbehave. – Hans Passant Apr 11 '23 at 21:04

0 Answers0