Debug C dll: symbols not loaded

[Ken_Brooks]

I have written a DLL in C in Visual Studio, meant to run under LabVIEW using Call Library Function Node. I tried to set breakpoints and debug it using Attach Process. This worked once, and then never again. The breakpoints show as hollow circles annotated with the message, "The breakpoint will not be hit. No symbols have been loaded for this document."

I have tried several things mentioned in this post:

1. I verified that the DLL is built in the Debug configuration.
2.The .pdb file is in the same directory right beside the DLL, with the same build date.
3. I turned off "Enable just my code" in the debugger options.

4. I cleaned and rebuilt my project.
5. I run the VI that calls my DLL, and it calls a trivial function in the DLL to get it loaded, then goes into a user-interface wait state. Then I attach to process.

At this point previous instructions will tell me to find my DLL in the Modules list. IT ISN'T THERE. Ever. Even though in my VI's front panel I see output which had to come from a function in the DLL, so it must have loaded.

Where do I go from here? Any ideas?

C and Labview code attached. Instructions:
1. If you need to rebuild the DLL, open the solution and build the FIRST project. Otherwise, the DLL is in the Debug folder.
2. Run Read1String.vi. You should see "message" fill with the words "Hello LabVIEW", which come from the trivial starter function in the DLL.
3. Attach to process, attach LabVIEW.exe
4. Set a breakpoint in the MakeFakeStrings function.
5. Press the Start button on the VI front panel and see if you actually hit the breakpoint.

LabVIEW 2017
Visual Studio Community 2017 version 15.9.6
C programming language (not C++)

[cordm]

I haven't looked at your code, but the way I debug DLLs is to start LabVIEW from Visual Studio so that I don't have to attach to process. Go to the project's property pages and set the Debugging->Command parameter to your LabVIEW.exe. When you start debugging, LabVIEW opens and you can run your VI.

[rolfk]

You can try to first attach to your LabVIEW IDE process and then load your VIs and run them. This should work. That said I always do it by letting Visual Studio launch LabVIEW and then loading the VIs inside LabVIEW. When you have to modify the DLL you anyhow have to kill LabVIEW in order to.be able to recompile the DLL.

Also you have to make sure that your LabVIEW VIs link to the latest debug DLL that you created. When you have a different version even if it was just a recompilation without real code change Visual Studio will refuse to let you to source level debugging as it considers your loaded DLL to be something that is not compatible with the current source code. It adds a new signature to the DLL every time it creates it and stores that signature in the pdb file and only lets you do source code debugging if the name and that signature match exactly.

[Ken_Brooks]

So, Rolf, how exactly do I make LabVIEW load the very latest build of my DLL? Do I have to go into the configure of the call node and select a different DLL, then go back to my own? What does it take to poke this into the most current state?

[rolfk]

At least unloading all and every VI that contains a Call Library Node that links to your DLL. That also includes VIs that you might have copied into the clipboard. As long as a VI with a Call Library Node is in memory it will hold a handle to the DLL and as long as there is one single handle to a DLL open, Windows will keep the DLL mapped into the process and you can go and replace the physical DLL on disk a million times, it won't replace the DLL already loaded into memory and mapped into a process.

I personally always shutdown and restart LabVIEW just to be sure. It does help to do the basic debugging in LabVIEW 7.0 which on modern computers starts up in a few seconds!