Undeletable Breakpoints, LabVIEW2026Q3

[Gryffin]

Hello,

I have a large project with many actors and VIs. In the past, I placed breakpoints throughout my code to debug things.

However, I have had to stop using breakpoints entirely, as they seemingly are broken.

1. They do not reliably "break" at the "point" that I specify.
   1. I am quite familiar on how to force the flow of execution, yet, even when a breakpoint is indisputably in the flow of execution, it only stops there ~50% of the time. It's not like it stops elsewhere, it fails to stop entirely (I am 100% sure that the code is executed though).
2. They become undeletable.
   1. This is the most infuriating aspect. There are breakpoints that I placed weeks ago which I have gone to and "Removed Breakpoint" numerous times. I go to my top-level VI in my project, CTRL+F for breakpoints, delete all instances found. I again go to my top-level VI in my project, go to "Edit>Remove Breakpoints from Hierarchy". This goes through, seemingly deletes them, even so that if I run it again, they do not show up. YET SOMEHOW, when I run my program (in the development environment), those breakpoints show up again.

Is there a way to fix this? Is there a way to entirely disable breakpoints within LabVIEW? They are too buggy to use in their current state, I am forced to used my own debugging VIs and methods to inspect things.

[Yamaeda]

Could it be some effect of having breakpoints saved in the VI as before and the new breakpoints in a separate file?

[rolfk]

Number 2 most likely are in reentrant VIs. You set the breakpoint in the actual VI but remove it in the clone that is opened when your program stops. Next time a clone is created from the original reentrant VI, it inherits the saved breakpoint from the actual VI.

That said, there certainly are still some weird things in the new debug manager since 2025 Q3.

When doing a "save all" after I've done some modifications on VIs and have some breakpoints or probes active, I frequently get a save dialog trying to save a "VI" that seems to take its name from one of the breakpoints or probes. I have to close LabVIEW at this point and restart to get rid of this "phantom" unsaved VI.

[Gryffin]

Sadly no, these are reentrant overrides of actor class methods which have existed for a long time, I do not create new copies on the disk of these culprit VIs with undeletable breakpoints.

[Gryffin]

That is correct, these VIs are all reentrant overrides of actor/class methods. However, I am aware that removing breakpoints from clones will not remove it from the actual VI. Hence, I always navigate in my .lvproj to the actual VI (not a clone), open that VI, and I am always selecting "Remove Breakpoint (This instance and all clones)":

Gryffin_0-1787239541894.png

(I took this picture immediately after running "Edit>Remove All Breakpoints from Hierarchy", which told me that it had removed this breakpoint. It did not, and clicking "Remove Breakpoint (this VI and all clones)" also did not remove the breakpoint (it disappears in the editor, shows up when launching the program, but only about ~50% of the time).

Additionally, the methods of "Edit>Remove All Breakpoints from Hierarchy" from my top-level VI on a fresh-boot of the .lvproj as well as the "CTRL+F" of all breakpoints in the project should have targeted the actual VIs and not the clones...

I have also experienced the "phantom VIs" which you speak of.

[Kyle97330]

There is a VI analyzer test that looks for breakpoints (Block Diagram -> Warnings -> Breakpoint detection).  Since VI analyzer can be set up to run on every file in a project, instead of just every VI that is in the "hierarchy", it may be better at finding things inside of dynamically loaded or dynamic dispatch calls.

[Gryffin]

That tool detected no breakpoints (despite them still popping up). Additionally, that tool is incredibly slow for even the simplest debugging...