none
Can't load executable to go with crash mini dump

    Question

  • I have a problem that I can't reproduce on my machine, so I asked for the mini dump file. I can open the file itself with no issues. If I try and debug, however, it says it can't find the executable for my project. I've placed the dump file in the folder where the binary files as well as the symbols live. I've even added that folder to the symbol file locations. I know for sure it is the same build of the executable as the customer has, so it's not a mismatch issue. 

    The biggest problem I am seeing is that if I open up the modules window, I see next to my executable "No matching binary." The solution I found was to right click the executable and click Load Symbols From -> Symbol Path. I navigate to the proper folder and I select the executable, but then nothing happens. It won't let me select my executable. There's no error that shows up or anything, the window cannot be closed except by clicking cancel. 

    It appears that 2 people that commented on an article have been having the same problem. Apparently I can't link to it because my account hasn't been verified or something. Paste "How to: Specify Symbol Locations and Loading Behavior" into google and it's the first link. 

    I haven't found a solution or workaround for the issue. Really all I'm trying to get is the call stack of when it crashes. So if someone has a solution that would be great. 

    Also, I'm using VS 2010 Ultimate. 

    Monday, June 3, 2013 8:58 PM

Answers

  • Hello,

    Glad to receive your reply.

    I opened it on that same computer, with the path matching the path specified in the dump.

    Based on this, I am afraid that the issue is related to your environment. From this article: Dump Requirements and Limitations, we can know that when you debug a dump file, the computer on which you debug must have access to the PDB symbol files and the binaries for the program. Visual Studio can cope with missing binaries for some modules, but it must have binaries for enough modules to generate valid call stacks. Otherwise, the "No matching binary found" message appears in the Modules window.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, June 5, 2013 5:24 AM
    Moderator

All replies

  • Hello,

    Thank you for your post.

    I would like to know what type of project you are working with and you have rebuilt the solution.

    As far as I know, when we debug the mini dump file, the executable and .pdb files must match exactly the version and build of the files used when the dump was created. You must have a matching pdb file for the binary that was executed with the minidump was created. So please use the new executable file to recreate the mini dump file and then debug it to check the result.

    Whether you can see the executable file in the folder when you select it?

    Please make sure that all the binaries, .pdb file and executable file in the same folder.

    I suggest that you check if you have chosen ‘All module, unless excluded’ in Debug->Options->Debugging->Symbols. If no, please choose it to check the result.

    If no help, please create a new similar dump file with another PC and then debug it locally to check if you can get the same issue.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, June 4, 2013 9:40 AM
    Moderator
  • Okay, I rebuilt the solution and sent it to the user who has been having problems so I could get a new crash dump that matches my current build. I'm still having the same problem. It says it can't find a matching binary. If I try to load it manually, I can't dismiss the window, except by pressing cancel. 

    I did some experimenting. I still can't reproduce the problem the user is having on either of my computers. Out of curiosity I loaded the executable onto my other computer, which doesn't have this project on it. I purposefully broke something so as to create a crash dump. I opened it on that same computer, with the path matching the path specified in the dump. This time it found the binary, but of course no symbols. If I go to the option the load the symbols manually, the window functions as it is supposed to. If I press open on a non-matching symbol file, it gives me an error informing me of the mismatch. All that experiment is to say that it needs to find the binary before it searches for the symbols. So loading the symbols here is not the issue since it won't let me open the binary. 

    I can see the executable in the folder and I can select it, but pressing the open button, which is not grayed out or anything, has zero effect. 

    I checked and the "all modules, unless excluded" field was already checked. 

    I also unchecked the box that requires the source to exactly match just for good measure, but that had zero effect. 

    More background: The application was originally an MFC C++ application. I was given the task of updating to work with new company libraries and file formats, which are all .NET C# based. The application is still most MFC based, but I have added some .NET calls. The application appears to fail before it gets to the .NET calls, which are towards the end of its execution. 

    Tuesday, June 4, 2013 5:53 PM
  • Hello,

    Glad to receive your reply.

    I opened it on that same computer, with the path matching the path specified in the dump.

    Based on this, I am afraid that the issue is related to your environment. From this article: Dump Requirements and Limitations, we can know that when you debug a dump file, the computer on which you debug must have access to the PDB symbol files and the binaries for the program. Visual Studio can cope with missing binaries for some modules, but it must have binaries for enough modules to generate valid call stacks. Otherwise, the "No matching binary found" message appears in the Modules window.

    Best regards,


    Amanda Zhu [MSFT]
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Wednesday, June 5, 2013 5:24 AM
    Moderator
  • Having the exact same problem. When opening a crashdump generated from an exe that I compiled from source just minutes earlier, the Modules window tells me that the main .exe cannot find its symbols, despite the crashdump being located in my build output directory containing the original .exe and its PDB. I similarly cannot dismiss the Load Symbols From -> Symbol Path window to try and load them manually.

    The "Load Symbols From" dialog will also only allow me to select .dlls and .exes, not .pdbs for god knows what reason.

    Oddly, many of the .exe's dependency DLLs load their symbols just fine from PDBs in the very same directory. Given that I just compiled them minutes ago with the very same VS instance, I'm baffled.

    Tuesday, January 7, 2014 10:45 PM
  • Having exact same issue.

    I have exactly the same executables at exactly the same path, I have the PDBs in the same directory. When I fire up the debugger, no symbols are loaded. When I try to load them manually it prompts for the executable but doesn't allow me to load it - the "Open" button doesn't work.

    Friday, June 10, 2016 9:37 AM
  • Very much the same issue: I have a mini-dump file (.dmp) (from production, built in Release).

    I have built the matching executable, along with all .dlls.  I try to debug the .dmp.  It requires some .dlls.  The .dmp refers to production directories, so I provided the local path - but the debugger doesn't find the .dll.  Therefore I manually provide the path (in fact the same path).  Now, although the path is found in the file-opening dialog and the file (a .dll) matches the "executable files" prototype, and the filename is present in the 'File name' box and the 'Open' button is available (blue-circled, not greyed), clicking it just causes the .dll filename in the 'File name' box to be highlighted and no other action.

    Something's wrong here!

    Thursday, April 5, 2018 10:42 AM
  • I have the same issue, using:

    Microsoft Visual Studio Professional 2015

    Version 14.0.25431.01 Update 3

    This is a really annoying problem, since my customer has frequent crashes that I can't reproduce at all and this feature is exactly meant to give insight into these cases.

    In reply to Amanda Zhu the problem is not that the pdbs are missing, everything IS in place, but VS just doesn't accept it but also doesn't give any indication on why it (incorrectly) refuses to load the binary and its symbols. It's as if the 'Open' button in the 'No binary found: Browse for <binary.dll/exe>' dialog is not properly connected to anything.

    Wednesday, December 5, 2018 11:25 AM