2017-09-24 07:39 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000162Cheat Enginepublic2012-04-23 22:43
Assigned ToDark Byte 
Summary0000162: Choosing "Find out what writes to this address" always results in BSOD
DescriptionWhen choosing the "Find out what writes to this address" option, my system always becomes very slow for a few seconds, then freezes for a few more seconds before giving a BSOD that says "A clock interrupt was not received on a secondary processor within the allocated time interval".

When setting the affinity of CE and the game to use one core, the same behaviour happens but without a BSOD, and instead the system just restarts. When forcing my system to use once processor core it still behaves extremely slowly when this option is enabled, but I'm pretty sure it never actually crashed when doing this.

Using the CE Kernel routines changes nothing, nor does using the windows debugger as opposed to the VEH one.
Additional InformationAMD FX-6100 Six-Core Processor 3.30 GHz Processor
16.0 GB DDR3 RAM
Gigabyte 990FXA-UD3 Motherboard
BIOSTAR Radeon HD 6850 GFX Card

Previously, I had a different motherboard and a 4-core AMD Athlon processor, and I did not experience this issue whatsoever. I've updated to the latest BIOS with no effect.
Attached Files




r2bl3nd (reporter)

I forgot to mention that I'm running Windows 7 Professional 64-bit.


Dark Byte (developer)

Make sure you do not run ANY online game and try debugging the tutorial. See if it then happens as well

What you describe looks like either a online game is detecting the debugger and in turn destroys your system, or it's trying to load dbvm, but since you have an amd that's not going to work (I assume this is ce 6.1 ?)

Also, disable ALL options in settings->extra and only use the windows debugger or VEH debugger (NOT kernelmode debugger)


r2bl3nd (reporter)

This is CE 6.1.

I just set Cheat Engine's settings to default (I can't choose the kernelmode debugger anyway since my system doesn't support DBVM), closing all unneeded programs, and doing that part of the tutorial.

The moment the debugger started, as before, my mouse still moved for a few seconds but nothing else would respond. Then everything froze, and the blue screen appeared for a few seconds, but I was not able to take a picture in time.

I'd be interested in hearing anything else I can try out, as I'd be willing to do just about anything to help you try and fix the problem.


Dark Byte (developer)

Last edited: 2012-02-09 06:26

delete dbk64.sys , run the kernelmodule unloader.exe and reboot ce. That way you can be sure that it's not one of the driver functions causing the problem.

What you can do is completely uninstall your anti virus and reboot. Then try it (just disabling won't work, AV's tend to be as worse as a malicious virus)

anther (very unlikely) possibility: Did you break of some pins from the mainboard before putting in the cpu? (Perhaps you broke of the pins used for debugging...)

If nothing works, reinstall windows, a bsod usually means one of the drivers on your system is bad. (hmm, that reminds me, perhaps your computer has been infected with a backdoor rootkit that protects itself when a debugger starts)

And if you're overclocking, try setting back to the normal state. CE is known for pushing some overclocked systems right over the edge while specific overclock benchmark tools do not


r2bl3nd (reporter)

Last edited: 2012-02-09 07:06

I tried deleting dbk64.sys and running kernelmoduleunloader.exe, but the same thing happened as before. Removing my antivirus did nothing. I do not overclock my CPU either.

Is there any way to test to make sure all the CPU pins are functional? I highly doubt that's the problem but I'd like to know for sure.

I'll uninstall my antivirus next and see if that help anything. I use eset NOD32 Antivirus, but I have never had any issues with it and CE before.

I'll reinstall only as a last resort, but I've been planning on doing that soon anyway.

Thanks for your help so far.


r2bl3nd (reporter)

Ok, I've resolved the problem. On the 4th of this month there was a BIOS update that included the latest version of AGESA, which previously contained a bug that was causing this issue for me. Thanks for your help in this situation anyway.

-Issue History
Date Modified Username Field Change
2012-02-09 05:33 r2bl3nd New Issue
2012-02-09 05:37 r2bl3nd Note Added: 0000324
2012-02-09 05:58 Dark Byte Note Added: 0000325
2012-02-09 06:16 r2bl3nd Note Added: 0000326
2012-02-09 06:25 Dark Byte Note Added: 0000327
2012-02-09 06:26 Dark Byte Note Edited: 0000327
2012-02-09 06:53 r2bl3nd Note Added: 0000328
2012-02-09 07:06 r2bl3nd Note Edited: 0000328
2012-03-01 07:25 nonobobo Tag Attached: clicknter
2012-04-23 22:42 r2bl3nd Note Added: 0000345
2012-04-23 22:43 Dark Byte Status new => resolved
2012-04-23 22:43 Dark Byte Resolution open => fixed
2012-04-23 22:43 Dark Byte Assigned To => Dark Byte
+Issue History