"Object reference not set to an instance of an object" when opening source

Sysprogs forums Forums VisualGDB "Object reference not set to an instance of an object" when opening source

This topic contains 6 replies, has 2 voices, and was last updated by  Chris Shaw 1 year, 5 months ago.

Viewing 7 posts - 1 through 7 (of 7 total)
  • Author
  • #29942

    Chris Shaw


    I have a VS 2017 solution containing multiple vgdb ARM projects. Some of those projects use common source code, i.e. the file ADC.c from a folder may be used in more than one project. Where this is the case, attempting to open the source file results in the dialog box with the text “Object reference not set to an instance of an object”. The projects build correctly, and double-clicking the source to open it produces the error message but successfully ‘expands’ the file to show symbols.

    Using 5.5R4

    Any help appreciated.





    This should normally not happen, so most likely the issue is triggered by some rare combination of settings.

    Please try reproducing the problem from scratch (i.e. on a newly created set of projects) and share the steps we could follow to reproduce it on our side per our problem reporting guidelines.

    Please make sure you also share the relevant screenshots and the call stack from the “details” view of the error window.


    Chris Shaw

    I actually managed to recreate the problem quickly and simply. This time the error dialog shows “Cannot open file”, and I also saw that before. I seem to be able to switch between the two errors by closing/reopneing the solution and switching IntelliSense engine between Default (Clang) and Advanced Clang IntelliSense.

    I’m using Visual Studio 2017 (15.9.33) and VisualGDB 5.4R4.

    Steps to reproduce:

    1. In VS use File -> New -> Project
    2. Create a new solution and use Embedded Project Wizard.
    3. Choose a processor and template – in my case I used STM32L151R8-A and LED Blink.
    4. Add a second project to the same solution – I used the same options again with a different project name.
    5. In each project, remove the reference to the main .c file.
    6. Move the main file for the first project to the solution root – in my case this was EmbeddedProject1.c moved up one level next to the .sln file.
    7. In each project ‘Source Files’ filter, add a reference to the moved EmbeddedProject1.c file using ‘Add -> Existing Item’.
    8. Build solution.
    9. Try and open one of the references to EmbeddedProject1.c.

    I’ve attached a zip file containing a solution according to above. The file appears to be ‘openable’ on first load, but some processing occurs soon after solution load and then it cannot be opened.

    NB I’ve just tried this on another computer and it appears to be ok, so I wonder if something is messed up in my VS installation. I’ve previously cleared out my VS cache from %APPDATA%, but maybe I need to uninstall/reinstall.



    You must be logged in to view attached files.


    Thanks for the detailed repro steps. We have rechecked it in 2 different environments and unfortunately could not reproduce the issue. Both following the steps you described and opening the project you attached worked as expected.

    Most likely, it is indeed a VS-level bug on a specific machine (e.g. some cache or VS component is corrupt). You can try narrowing it down by creating GNU Make-based projects that do not require VisualGDB to be loaded into Visual Studio, reproducing the problem and then checking if the problem persists if you completely uninstall VisualGDB. If it still fails, the issue is definitely on the Visual Studio side.

    That said, if you are planning to have any non-trivial project structure, we would advise using the new Advanced CMake Project Subsystem. It natively supports multiple targets sharing the same BSP, emulation platforms, lets VisualGDB fully control the Solution Explorer window contents, eliminating many bugs caused by Visual Studio itself.


    Chris Shaw

    I cleared the caches and was still having the problem. After commenting before though about switching the error message by changing the IntelliSense engine, I selected the third option (Regular VC++ IntelliSense) for just one of the projects and all appears to be ok now. Both projects can open files without problem.

    So I’m going to blame Clang at this point. If I get the Clang IntelliSense Diag Console window then by changing those options I can see processing and errors. I’ve removed my local .clang-format file, tried a new one but each causes the same problem. Below is a common stack trace I can see on changing options.

    If you are able to help or point me at a better resource that would be appreciated.

    • This reply was modified 1 year, 5 months ago by  support. Reason: formatting


    Thanks for sharing the stack trace. This looks like a different error triggered by changing the “For Files Used by Multiple Projects” setting and opening a solution with 2 VisualGDB-based projects using the same file (and no non-VisualGDB projects using it). This explains why the project did not trigger the issue when we tried it with default global settings.

    Please try this build, it fully resolves the issue: VisualGDB-


    Chris Shaw

    Hmmm, yes it appears that I did have that setting on ‘Prefer Visual Studio IntelliSense’. And on my second environment (working fine yesterday) if I set the same option then the error starts happening there too.

    I’ve installed the beta version you supplied and that does indeed seem to fix it.

    Thank you very much for the assistance.

Viewing 7 posts - 1 through 7 (of 7 total)

You must be logged in to reply to this topic.