2018-07-18 22:15 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000197Cheat Enginepublic2012-12-23 01:27
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Summary0000197: newly set breakpoints do not trigger sometimes

Sometimes setting breakpoints (toggleing them to on, creating new one) doesn't break when it is reached. To work around this I have to remove it and then add it again (that is: toggle it twice, since it was already enabled)

I noticed this happens when
1. added new breakpoint then removed a previous one (was already in debugging mode, not sure if this still holds if the game is already running aka F9)
2. when already in debugging mode and setting new breakpoint then doing F9 to continue Running

In these cases, the newly added breakpoints do not trigger, to fix I just have to toggle the breakpoint to off and then back to on again

Additional Informationthis on win7 64bit (the x64 .exe of cheatengine is running) and cheatengine 6.2 (latest atm)

I'm not sure if this happens all the time, or just really very often
TagsNo tags attached.
Attached Files




Dark Byte (developer)

Which debugger interface do you use?
VEH, Kernel, or Windows ?


azkesz (reporter)

I don't know(Edit:it's windows), but it's definitely not Kernel (i don't have that driver installed nor dbvm)

I had hardwarre breakpoints (never used the software ones)
and lately I tried with "Try to prevent detection of debugger" to avoid game crashing and the issue still persists
Oh wait I see it's Use windows debugger


Csimbi (reporter)

This happens to me every time with VEH debugger. So, I always start with something fake that enables the debugger and sets a breakpoint, then I stop it right away - and then I can work normally.

There are other weird stuff (like "CTRL+C has been pressed" dialogs) every now and then, but when I reported in on the board, DB told me it's only me - so I gave up as I thought it was just me.


azkesz (reporter)

I think it's maybe something related to shadow breakpoints but I really don't know


Dark Byte (developer)

Can you reproduce this in the tutorial? (Or is it on steam games only ? )
If so, can you write a step by step method on how to reproduce it


azkesz (reporter)

Last edited: 2012-12-19 13:31

I'll try, but so far I only tried it and happens in farcry3.exe (in fc3.dll actually) and it seems to happen pretty much all the time. But I'll try in tutorial and let you know

EDIT: oh, it doesn't really use steam, but it does use the reloaded steam api but no internet connection or stuff, nor steam needing to be installed), it uses that crkd steam*.dll, but I think that's what you meant anyway :-" (steam games... got it)


azkesz (reporter)

Last edited: 2012-12-19 16:04

EDIT: if you see this, at the end of this post, go to post 0000407 and ignore the ones in between(since they are mostly farcry3 dependent) but 0000407 is tutorial reproducible, thx.
oh yes, this is when it happens apparently, only when all 4 hardware ones are full, and then I need to put a new one, so I delete an existing one and put the new one, that new one is never triggered (setting/deleting them while in already Break mode, ie. not running)

Although I do have to say, I remember this issue happening even when not all the breakpoints were reach (though I may be wrong and I simply was deleting the last and then adding a new one when it was happening)

step 5
find address, find out what accesses this address
about 4 addresses
get to the one that writes
which is:
Tutorial-i386.exe+23739 - 89 10 - mov [eax],edx

put a break on:
Tutorial-i386.exe+2376C - E8 EF02FEFF - call Tutorial-i386.exe+3A60
do Change value so it breaks
now put a breakpoint on:
Tutorial-i386.exe+2373E - 8B 80 5C040000 - mov eax,[eax+0000045C]

then put a breakpoint on:
Tutorial-i386.exe+23746 - 3B 45 F4 - cmp eax,[ebp-0C]
at this time all 4 are full (3+the find out one)
now F9 to run it, then change value again after it is running to break(*)
now remove the breakpoint from cmp and put it on
Tutorial-i386.exe+23746 - 3B 45 F4 - cmp eax,[ebp-0C]
then F9 to run again, and this one won't trigger

if it doesn't break there (*) so it's in running mode, then it will work (guessing: something with shadow breakpoints pending deletion so allocating a new one, a 5th at the time is actually postponed for when Running but it somehow fails to allocate it and is thus forgotten, when viewing breakpoints list it does show like so, 5 breakpoints all but 1 are active Yes, that one is No, and pending deletion is Yes, although the newly added one is not yet active, it should be only after the pending deletion is executed - ok clearly you know better, sorry for even saying all this xD but i like jumping to conclusions lol)

PS: i know I fail at conciseness, apologies in advance

Also, CE is great work! really. It's like gamewizard+dosice combined :)
When I get a job(aka income) I'll remind myself to donate.
Thank you for your great work, much appreciated!(I mean it)


azkesz (reporter)

it happens(in farcry3 at least) even with just 2 breakpoints, but I just have to be in Currently debugging state when adding the new breakpoint and it sometimes works if I step through until i reach the place of the new breakpoint and disable it and set it again, then F9 would make it trigger in the future


azkesz (reporter)

something new happened, regarding my previous post, while both breakpoints were triggering, while I was at the second one (the new one) I pressed Shift+F8(execute til return) and it stopped somewhere higher up the hierachy (clearly not after that function returned, but after some other higher up functions returned) and then after this F9 wouldn't trigger this new breakpoint anymore. It would only trigger on first, so I stepped thru, from the first, only like 5 steps again and inside a call is the new breakpoint still there but disabling it and enabling it again worked, as in triggered again after F9, but again if I do the Shift+F8 when it triggered, then F9, it won't trigger again...
Not really sure why Shift+F8 doesn't show exactly the point of its return... but there are only 2 breakpoints that I have set (and maybe shift+F8 needs one too, so max 3 of 4 used)

first bp is:
FC3.RunGame+53D5B7 - 3B 86 C0000000 - cmp eax,[esi+000000C0]

second is:
FC3.RunGame+5CF0C9 - 8B 41 3C - mov eax,[ecx+3C]

only a few F7 steps away from first
in farcry3 v1.03 reloaded :-"
(farcry3.exe fc3.dll aka dx9 one)

I did do some binary modifications for fc3.dll and the one in memory currently was:
FC3.RunGame+53D5D5 - 7C 0C - jnge FC3.RunGame+53D5E3
this allows picking sound to be heard(and whatever else comes with it, except picking the grenade up) if you change it to jmp(it was changed to jmp)

and these(2 above breakpoints) only trigger when you're trying to pick up some grenades laying around on a table (in a wanted dead mission from AM 12 outpost) on top of the shack - so it's kinda tough to reproduce...
I'm currently still on it since I'm trying to make it pick up the grenades when I already have over 12(the limit) grenades in my "inventory" (but without changing the limit)

the current binary(in file) modification that I had are these:
Comparing files FC3.dll.103originall and FC3.DLL
0054080F: 7E EB
00541B5A: 73 90
00541B5B: 0C 90
00541B63: 75 90
00541B64: 03 90
005D4465: 0F 90
005D4466: 4D 90
005D4467: F8 90
005FA699: 0F B0
005FA69A: 9C 01
005FA69B: C0 90
0066D163: 66 57
0066D164: 0F BF
0066D165: 6E 18
0066D166: 46 79
0066D167: 14 00
0066D168: 0F 00
0066D169: 5B 90
0066D16A: C0 90
0066D16B: F3 90
0066D16C: 0F 90
0066D16D: 59 90
0066D16E: 46 90
0066D16F: 1C 90
0066D170: 57 90
0066D171: F3 90
0066D172: 0F 90
0066D173: 2C 90
0066D174: F8 90
006D519A: 0F B0
006D519B: 9F 01
006D519C: C0 90
006D7647: 7E EB
006D8F56: 0F B0
006D8F57: 9F 01
006D8F58: C0 90
0070C434: 72 EB
0070C61A: 72 EB
0070C7F1: 72 EB
0070C9E0: 72 EB
008E1BC0: 0F 90
008E1BC1: 8D 90
008E1BC2: 49 90
008E1BC3: FF 90
008E1BC4: FF 90
008E1BC5: FF 90
008E23B3: 7C EB
008E2427: 72 EB

368ea5bd57d36003b70403783d454ebc *FC3.dll.103originall
where this is the fc3.dll from crack dir in Far.Cry.3.Update.v1.03-RELOADED
(the crack itself is unseen in these diffs, since both dlls have it)
the binary modifs I have is for my attempts to ignore the upper ammo/mines/c4/molotov/grenades limit when looting/picking up when thrown or encountered/buying from shop (work in progress xD)


azkesz (reporter)

I had 3 active working breakpoints and I lost 2 for some reason(they weren't triggering anymore, and I know they should) while debugging, then I went ahead and took a look at shadow breakpoints, and here's what I see :D

I did use some F7, F8 and F9, but F9 would really trigger the main/first breakpoint all the time (which is what I expected) - maybe this matters


azkesz (reporter)

Last edited: 2012-12-19 15:41

those images weren't good enough, because of the Type column size cannot see hwbp number
I retry here

the only one triggering is the first in the list (1of2)


azkesz (reporter)

Last edited: 2012-12-19 15:50

Ok so I reenabled those 2 breakpoints by toggling them twice (ie. disable then enable) and they were added with Yes at the end (all this while in debugging mode not on Running). All well and good, F9 shows they trigger again. Then I did some F7, nothing interesting happened then I F8(Step over) a call and this added a shadow breakpoint right at the end (in Ctrl+B list) unfortunatelly after F9-ing right away I noticed that the last active breakpoint(the one right above this new shadow breakpoing) was nolonger active, only the other two were triggering.
(Note that I F9 several times to see them triggering)


I'll try reproduce this with tutorial next


azkesz (reporter)

I cannot reproduce the above, but I can reproduce something else:
While having 1 breakpoint set and it triggering(so we're in Currently debugging mode) then stepping over a call with F8 will create a shadow bp with waiting for deletion, then go ahead and set a new breakpoint (this would be the 3rd in the list, although only 2nd one active) and this bp will never trigger (go ahead and F9)

So here's that reproduces in Tutorial-i386.exe from CE 6.2
go to Step 5 in tut
Tutorial-i386.exe+23739 - 89 10 - mov [eax],edx
breakpoint that (which modifies the value when button pressed)
then click Change Value in tut so that bp triggers
now F8 until after this call (which is on the same page)
Tutorial-i386.exe+2376C - E8 EF02FEFF - call Tutorial-i386.exe+3A60

after this, Ctrl+B should show that shadow bp added (with pending deletion)
then go inside the next call
Tutorial-i386.exe+23786 - E8 A5570100 - call Tutorial-i386.exe+38F30
and breakpoint at the beginning of it
then F9 to run, press Change Value to trigger, it will trigger first bp, now F9 again, should trigger second but doesn't

tested this twice, works as such
to workaround, I've to go to that bp and toggle it twice(ie. disable and enable) but without doing any F8s in between, or do it while Running


azkesz (reporter)

note: anyone else reading this, to "show shadow breakpoints" right click on the list in Ctrl+B (View->Breakpoint list)


azkesz (reporter)

This is probably related, but there's a small issue with showing the breakpoints in list:

Let's start from here, game is currently running and I'm showing shadow breakpoints in list:
All seems good except those hardware breakpoints should've been deleted(?) since the game is running (it would've got around to it)

then, I right click and choose to not show shadow breakpoints and the following is shown:
notice these are those hardware breakpoints that are supposed to be deleted(and are thus shadow breakpoints) and these are not the ones that should be showing now, but instead the ones that are active are not shown.

Next, to fix this, I close the window(the Breakpoints window only), and then I open it again from View->Breakpoints list
this time all shows exactly how it's supposed to show. The view is correct.

Next I right click and choose to show shadow breakpoints
and it works as expected, except I wonder why those aren't yet deleted(with pending) but the view is correct.

Next, I right click and choose to not show shadow breakpoints, and we're back to bad view (shows only the shadow breakpoints)

So again to fix, i close the window and show it again:
correct view.

Hope this helps,


Dark Byte (developer)

Last edited: 2012-12-19 18:38

About shadow breakpoints. If you delete a breakpoint it doesn't get unregistered in cheat engine immediately, but waits a while till there has been no debug event for several loops.
This is because the game might have stacked up 50 or more breakpoint events during the handling of the previous breakpoint, and one of them might be the one you just deleted. If cheat engine didn't remember it had set that breakpoint, it would tell the game it doesn't handle it, and thus crash the game.
This way, when ce recognizes that breakpoint, it just ignores it and continues the game.
With steam games they often have a LOT of breakpoints and exceptions not caused by cheat engine(it's an anti debug thing), causing the "No breakpoint" event to happen often, causing the shadow breakpoints stay in memory for a long time. (or never get deleted at all)

But I don't think it is the cause for the breakpoint to be ignored, as it will search through the active list first

anyhow, seeing it's a steam game, I recommend running debugview from sysinternals, for some reason I found the debugger to work more effective when that's running


Csimbi (reporter)

I tried reproducing this with the tutorial.
The first instruction is caught correctly in the tutorial, but then the tutorial crashes.
I put this in a new bug report, see 0000198 .
Probably a different bug though.


azkesz (reporter)

Last edited: 2012-12-20 00:55

I was using windows debugger you used VEH, I also have the "Try to prevent detection of debugger" enabled

EDIT: and I tried it on the 32bit tutorial with the x64 CE


Csimbi (reporter)

The exact same bug (first breakpoint does not trigger) happens with the VEH debugger. Did with Steam games; the only steamless game I checked so far is Drakensang - works fine there...


azkesz (reporter)

I tested with debugview running so far seems the same

I noticed that I can unset and set again a breakpoint which wasn't triggering - all this while in debugging mode (not while running) and it will trigger next time(F9-ed), so doesn't have to be unset/set while in running mode to do so.

The losing breakpoints(them not triggering) after using F8 still persists, it feels like a hassle to keep track of them and be sure but meh it's ok considering all other features of CE available

I've been kinda learning how to use CE these past days without actually reading about it or anything like that, it's tougher like this I suppose but it's how I want it, so handling breakpoints like this is kind of in the same style

@Csimbi, in my case it was the newly added breakpoint(ie. last) not triggering, usually the first would always trigger even when losing some breakpoints along the way (as you can see in above posts)

I've been spending some serious hours per day with CE and farcry3 messing around, it's quite enjoyable especially since I've never been able to do something like this before(to actually be able to find things and change them as I wanted)

And I discover features in CE which I say I want, I look for them and they are there already.

So, I am understanding that this issue happens due to steam games anti debugging wannabe techniques... maybe, but hmm, as I could reproduce some with the tutorial maybe it's a CE issue. I am babbling... stopping


azkesz (reporter)

sometimes I delete ie. the second pointer in list, but the last one gets deleted, however this only seems to happen in list view, but in fact the real pointer that I selected got deleted(though the breakpoint list doesn't show it as such). Maybe it's related to the current issue.


azkesz (reporter)

about the above,
closing the Breakpoints list window and re-opening it shows indeed that the right pointer was deleted, it's just that the window contents were updated incorrectly


azkesz (reporter)

Last edited: 2012-12-22 01:59

something else happens, I believe related, even after re-opening the breakpoints list window, doubleclicking on the last 2 breakpoints moved the cursor on the breakpoint that's 2 above and it thus lists this one (because if I double click that bp it still shows the same address) - I had 1 write bp and 4 on execute (on this order), the first 3 work ok, just the last 2 jump on previous ones that are 2 bps away (5th jumps to 3rd, and 4th jumps to 2nd)

EDIT: I was in debugging mode all the time here, but after I went into running mode AND i re-opened bplist window then they showed right: and it seems that I had 1 onwrite, 2 on execute, and 2 on read/write maybe that's why the last 2 wouldn't show anything, but either way some inconsistency between what is and what's shown in the window.
EDIT2: the first 3 were break onhit and last 2 were Find Code


Dark Byte (developer)

The breakpoint list window is just a view into the actual breakpointpoint list stored in the debugger class, so I doubt it has any effect on the main bug.

I'll see about fixing those things, but they are only visual bugs

-Issue History
Date Modified Username Field Change
2012-12-18 04:08 azkesz New Issue
2012-12-18 10:51 Dark Byte Note Added: 0000392
2012-12-18 10:51 Dark Byte Status new => acknowledged
2012-12-18 16:53 azkesz Note Added: 0000393
2012-12-19 00:02 Csimbi Note Added: 0000395
2012-12-19 00:25 azkesz Note Added: 0000397
2012-12-19 00:42 Dark Byte Note Added: 0000398
2012-12-19 13:29 azkesz Note Added: 0000400
2012-12-19 13:31 azkesz Note Edited: 0000400
2012-12-19 13:31 azkesz Note Edited: 0000400
2012-12-19 13:48 azkesz Note Added: 0000401
2012-12-19 14:53 azkesz Note Added: 0000402
2012-12-19 15:09 azkesz Note Added: 0000403
2012-12-19 15:35 azkesz Note Added: 0000404
2012-12-19 15:39 azkesz Note Added: 0000405
2012-12-19 15:39 azkesz Note Edited: 0000405
2012-12-19 15:41 azkesz Note Edited: 0000405
2012-12-19 15:49 azkesz Note Added: 0000406
2012-12-19 15:49 azkesz Note Edited: 0000406
2012-12-19 15:50 azkesz Note Edited: 0000406
2012-12-19 16:03 azkesz Note Added: 0000407
2012-12-19 16:04 azkesz Note Edited: 0000401
2012-12-19 16:06 azkesz Note Added: 0000408
2012-12-19 17:39 azkesz Note Added: 0000409
2012-12-19 18:38 Dark Byte Note Added: 0000410
2012-12-19 18:38 Dark Byte Note Edited: 0000410
2012-12-19 22:16 Csimbi Note Added: 0000411
2012-12-20 00:52 azkesz Note Added: 0000412
2012-12-20 00:55 azkesz Note Edited: 0000412
2012-12-20 02:15 Csimbi Note Added: 0000413
2012-12-20 03:33 azkesz Note Added: 0000414
2012-12-22 01:34 azkesz Note Added: 0000420
2012-12-22 01:44 azkesz Note Added: 0000421
2012-12-22 01:53 azkesz Note Added: 0000422
2012-12-22 01:57 azkesz Note Edited: 0000422
2012-12-22 01:59 azkesz Note Edited: 0000422
2012-12-23 01:27 Dark Byte Note Added: 0000423
+Issue History