# Debugging dll sometimes cause load symbol problem

**URL:** <https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829>\
**Category:** PLECS\
**Tags:** dll\
**Created:** [February 2, 2026, 11:09am UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829 "2026-02-02T11:09:50Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![vishweshgm](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/vishweshgm/32/2495_2.png) [@vishweshgm](https://forum.plexim.com/u/vishweshgm)\
**Post date:** [February 2, 2026, 11:09am UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/1 "2026-02-02T11:09:50Z")

</div>

I have a model A that has another model B as a sub-module. I have kept a DLL block inside submodule B and linked it to correct dll file. Through visual studio I want to debug while simulation. So I use attach process feature to attach it to plecs.exe with the name showing the model A. Everything usually goes well.

But sometimes I see this error:

 ![image](https://europe1.discourse-cdn.com/flex006/uploads/plecs/original/2X/c/ccfdad6516c24933d3e176d4948e024815c454dd.png)

Once this error starts popping up, no matter what I try, it never solves. I have to revert back all the changes I did in plecs and restart laptop and freshly start again it works.

So any of you have idea what happen here?

---

<div class="post-metadata">

**Author:** ![Bryan\_Lieblick](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/bryan_lieblick/32/10_2.png) [@Bryan\_Lieblick](https://forum.plexim.com/u/Bryan_Lieblick)\
**Post date:** [February 2, 2026, 6:59pm UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/2 "2026-02-02T18:59:55Z")

</div>

Hi Vishwesh,

Visual Studio official documentation provides [guidance on this topic](https://learn.microsoft.com/en-us/troubleshoot/developer/visualstudio/debuggers/troubleshooting-breakpoints#no-symbols-have-been-loaded-for-this-document). There is quite a bit of other guidance regarding this error across stack overflow and other programming sites as it often relates to the build process, loading the wrong dll, caching of symbols, etc.

A few other thoughts related to PLECS integration:

- If PLECS has crashed, use your task manager to ensure no `plecs.exe` instances are lingering. Windows will not unload a DLL while the process lives and VS will silently keep stale symbols. You want to ensure you’re connecting to the correct `plecs.exe` instance.
- Best practice would be to attach the debugger before running the model in PLECS.
- If the same DLL is loaded multiple times in one simulation or even multiple different simulations [one needs to be cautious](https://forum.plexim.com/t/how-to-write-dll-to-make-it-reentrant/1167).

Regards,  
Bryan

---

<div class="post-metadata">

**Author:** ![vishweshgm](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/vishweshgm/32/2495_2.png) [@vishweshgm](https://forum.plexim.com/u/vishweshgm)\
**Post date:** [February 3, 2026, 5:33am UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/3 "2026-02-03T05:33:01Z")

</div>

Hi Bryan,  
Thanks for your response. I followed the VS documentation and loaded the suggested symbols PDB file. However, even after selecting the correct PDB file, I still get the message: “could not load the symbol.”  
For context, PLECS had crashed earlier, and I restarted it before this issue occurred. At the time of the crash, I made sure to open Task Manager and manually end the lingering plecs.exe process.  
I’d like to clarify the best practice here. Do you mean the recommended sequence is:

1. Load the model in PLECS
2. Attach VS to the PLECS model’s executable (the one titled myModelName in my example image)
3. Run the model simulation

 ![image](https://europe1.discourse-cdn.com/flex006/uploads/plecs/original/2X/b/be5e008587a238fe24439a0f93937fc2f60b8fd2.png)

---

<div class="post-metadata">

**Author:** ![Bryan\_Lieblick](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/bryan_lieblick/32/10_2.png) [@Bryan\_Lieblick](https://forum.plexim.com/u/Bryan_Lieblick)\
**Post date:** [February 5, 2026, 6:51pm UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/4 "2026-02-05T18:51:23Z")

</div>

Yes, that is the recommended sequence. Once PLECS crashes, the operating system and VS Code are responsible for managing the DLL resources.

After the crash have you tried:

- Clean Solution → Rebuild (in Debug mode) ensuring that DLL is fully deleted
- Tools → Options → Debugging → Symbols and click **Empty Symbol Cache**
- Performing the above steps and restarting Visual Studio?

Of course one needs to ask - why is PLECS crashing? With a DLL block it’s typical that the crash is a result of actions within the DLL. Presumably you are using breakpoints for this purpose, but one could always default back to clunkier print debugs, and then revert back to a more typical workflow.

---

<div class="post-metadata">

**Author:** ![vishweshgm](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/vishweshgm/32/2495_2.png) [@vishweshgm](https://forum.plexim.com/u/vishweshgm)\
**Post date:** [February 16, 2026, 6:02am UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/5 "2026-02-16T06:02:30Z")

</div>

Past week I tried with recommended sequence, ie. always attach to process first and start simulation. This really helped. I didn’t face any issue for a week now.

Regarding cacheClear suggestion, I’ll try once it crashes again and update here.

Thanks

---

<div class="post-metadata">

**Author:** ![Bryan\_Lieblick](https://dub1.discourse-cdn.com/flex006/user_avatar/forum.plexim.com/bryan_lieblick/32/10_2.png) [@Bryan\_Lieblick](https://forum.plexim.com/u/Bryan_Lieblick)\
**Post date:** [February 17, 2026, 1:49pm UTC](https://forum.plexim.com/t/debugging-dll-sometimes-cause-load-symbol-problem/2829/6 "2026-02-17T13:49:50Z")

</div>

Glad to hear that makes an improvement. Thanks for the update!
