Since the question does not provide much debugging information, I will try to provide some common solutions based on my personal experience and the few hints I can get from your context.
Seem something you may get when the executing code is not up to date with your Visual Studio environment. I suggest that you try and restart the OWSTIMER process manually, since it is very common for it to be "stuck" using an old cached version of the actual dll.
If you can, I suggest you install the CKS-Dev extension, it provides some contextual menus inside Visual Studio to manage common SharePoint related task, and this includes restarting most of the SharePoint related services (restart IIS, recycle app pools, restart the OWSTIMER one and so on).
I notice that the code is under an
#if DEBUG directive. While I think this may be pretty obvious, try to double check and confirm that you haven't by change switched to release mode without noticing (or some co-worker did that, I seem to recall that the compilation mode is a setting that gets saved to source control).
Sometime Visual Studio can trigger a bug - the dll in the GAC gets "locked" by the visual studio instance process. If that is the case, just restarting Visual Studio does the trick. Back in the VS2010 days it wasn't uncommon either for the debugging service to crash either (usually that would trigger an error window, but non always) - this was also most of the time fixed by a Visual Studio restart.
Some other ideas:
I had multiple times see the error message "the following break point cannot be set" get triggered even when the break points were actually working. If that is the case, you should be safe ignoring it. Also, deleting all the break points from the Visual Studio debug menu can fix this bug.
Also worth a try, if everything else fails, is trying to trigger the execution to stop with the
System.Diagnostic.Debugger.Break() method (
Debugger.Launch() may work too). And if possible try to add some sort of feedback that may ensure you that the updated code is actually running - a simple log to uls line with a number message you increment at each attempt may be enough.