I hit largely the same $System.OBJ.%Save <ZSG> error, in a code you cannot see, of course. After reading this thread I realized that the only unusual thing I did is to give my programmatically created project a numeric name. Apparently, there is a check inside %Save: if numeric it must be an object ID and not name… The error was gone as soon as I added a letter in the beginning of the name.

I am also on Cache 2017
 

Dmitry, thanks for the advice. The first function is not available in this Cache version and it will actually export, not just convert code to an array. The Atelier one calls the $preprocess command in question inside its stack and Atelier is not available in this Cache version either. The last function would be perfect but it also calls the $preprocess command in question and this is exactly where the call for this specific class dies, inside $preprocess.

One late addition: I just lost this debugging functionality again, looks like because my code was going into a different namespace via zn "nsp". If I put the first breakpoint AFTER this zn, the cursor does not go to it and the yellow box does not appear. However, if I put my first breakpoint AT zn, the yellow box appears at it and stays with me after the breakpoint as well. Can't say it's a feature but then what?? smiley

Losing debugging capabilities, Scenario #2.
A fellow programmer also lost her debugging capabilities some time ago though for different reasons and with different symptoms. I am not dead sure what happened in her case but it looks like some unfortunate combination of User Roles and Service Settings as defined in Management Portal. We discussed it today and she tried a few things. Changing the studio login user helped as well as changing localhost in Cache Server Manager to an actual IP address. Using Remote System Access from the cube was beneficial as well.

Alright, this particular saga suddenly came to the end revealing the bug, my own one. But it is sort of educational so some details. I am implementing source control like features on and off while inheriting one of the features from a previous programmer. The latter feature which I preserved was about adding a timestamp with the compilation time to the changed routine in the overwritten source control method, OnAfterCompile. OnAfterCompile was adding this timestamp, resaving the routine  directly in one of the internal routine globals, and it did NOT recompile the file again. That effectively still had the file internally marked as saved and compiled, no little cross in the Studio's routine tab, BUT that threw the .OBJ file mapping to the routine source code enough so the debug yellow box would refuse to appear and the cursor would not move from the first line. Many self eye-rolling emojis here...

How did I discover it? I need to modify this custom source control class and it was annoying to do so while the source control was on so I turned it off, moved functionality to my test routine, and observed with incredulity the long lost yellow debug box again....

P.S. On the plus side, I learned a lot about inner Cache workings due to this largely self-inflicted wound and I am happy it is over.

Robert, that's what I initially thought too and it's indeed mostly so but not 100%: the old style %RI is actually calling the new style ROUTINE^%R, with Audit classes and all. Just no source control class suspenders smiley . I see no technical reason not to have them in ^%R but they are not there. The ZSAVE implementation is not available.

So this is why I am trying to tackle this problem from the Audit side. Any ideas? I am thinking of a process monitoring the audit trail records but I don't quite like this solution. In any event, is there anything beyond monitoring?

That's exactly the problem: the new breakpoint is reached but no yellow box and the cursor stays at the routine's first line. The code is executed though because the variable set right before this single breakpoint gets defined correctly as per Watch. I did follow your instructions except I still used the corrupt routine.

I doubt I can reproduce this corruption intentionally because that requires understanding why it got corrupted in the first place and that is still a mystery to me.

Robert, a bit more info after I tested a bit more:

1) The first program above, TestAG exhibited the same corrupt debugging behavior when I set it up as debug target for another project however this another project started debugging alright when I switched to a yet another debug target:

2) Test in this comment above leads me to think that the corrupt debug behavior might be associated with a program more than with a project. I don't think it is associated with the old style b break since it behaves correctly, the same as before.

I am not sure I am falling into the .obj code with this problem but maybe I do.  Just to be clear what is happening and what is not, a couple of screenshots.
1) TestAG^TestAG is the debug target, hand-written routine, and I pressed Go once, so presumably the debugger now sits at this breakpoint. However, no yellow box and the cursor is one line up. Shift+F11 does not make the cursor or the yellow box to appear anywhere else (I have other breakpoints too).

2) This is normal behavior. last is the debug target and the cursor correctly stops at the programmatic breakpoint with a suitable yellow box.

So any advice how to fix it?