‎08-19-2026 06:09 PM
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.
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.
‎08-20-2026 04:25 AM
Could it be some effect of having breakpoints saved in the VI as before and the new breakpoints in a separate file?
‎08-20-2026 05:05 AM
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.
‎08-20-2026 10:16 AM
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.
‎08-20-2026 10:27 AM
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.
‎08-20-2026 11:57 AM
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.
‎08-20-2026 12:56 PM
That tool detected no breakpoints (despite them still popping up). Additionally, that tool is incredibly slow for even the simplest debugging...
‎08-24-2026 03:23 PM
I'm having a very similar issue. It's a large project with reentrant VIs in PPLs. Sometimes I'll add a breakpoint and then later remove it, and it simply won't go away -- it'll no longer show up in the VI or in the Debug Window, but my code will still stop where the breakpoint was even though the block diagram no longer indicates that there's a breakpoint.
I lost an hour to this issue earlier today and it seemed to go away after restarting LabVIEW and clearing my compiled object cache...maybe that'll help in your situation?
Hoping this gets addressed with SP1!
‎08-24-2026 05:27 PM
Hey Carl, I'm sorry to hear that you're having similar issues.
Unfortunately, I've clear my compiled object cache and restarted numerous times. The only solution I've found is to abandon breakpoints entirely and in any VIs which have these immortal breakpoints, I am forced to "Disable Debugging". Thankfully, this disables the persistent breakpoints.