Cheat Engine

[Laphicet Crowe]

Just updated to 6.8.3 today and am noticing, no matter which game process I try opening, Cheat Engine locks up on me. The game itself doesn't appear affected by this. I've even tried wiping settings and rebooting, but to no avail.

EDIT: Even simply selecting the Process menu locks it up

[Dark Byte]

Perhaps you need to tell your AV to allow CE?

Also what Windows build ?

And have you tried waiting a while? e.g 10 minutes ?

[Laphicet Crowe]

Oops, well firstly, I'm running Windows 10 and only have Windows Defender. Not sure why I'd need to wait 10 minutes after opening a process, but no I've not tried that. I had run 6.8.2 prior and that runs flawlessly. It's the 6.8.3 update where the problems began.

[Dark Byte]

Nothing got changed in the processlist and same compiler and lcl lib as 6.8.1, so i do think it may be a matter of whitelisting CE

[Bavarian]

I found the following sequence got 6.8.3 UI hang.

debugger settings: VEH, break on unexpected breakpoints

1. attach to the process, activate several table entries
2. close process, relaunch it.
3. re-attach to the process as debug. process in a while throws exception, exception is not caused by CE. it's process internal logic.
4. CE UI hangs, i thinks trying to get my answer on "keep current table" vs open debug view to show exception.

if I first attach without debug, answer on question "keep current table " and then attach debugger, this will be ok with no UI hang.

[MarcRené]

Strange behaviour with 6.8.3 on my system, too.

Installed CE, resetted settings to default. Clicked on "select process", does not matter what process I choose. Almost immediately the GUI hangs, Title of CE window says "No Response".

Windows 10, 64 Bit with Windows Defender as AV.
Excluded the complete CE folder from Defender but no change
CE 6.8.2 works fine.

[Dark Byte]

6.8.2 still works fine?
What happens if you copy the exe from 6.8.2 over to the folder of 6.8.3 and run that ?


Do you have any special shell extensions running ?
What language is windows configured to? English?
Do you have symbol files or paths in your registry?


other things to do

go to settings and disable the option to get process icons
see if dpi aware disabled has any effect as well
delete all files in the autorun folder of the ce install
try waiting 2 hours (lol)
delete symsrv from the win32 and win64 folders

[MarcRené]

[Dark Byte]

symsrv is responsible for downloading the symbol files for the attached target (mainly windows dll's)

Normall it's inactive unless your environment variables contain a symbolserver path in which case it will download the .pdb files and store them on disk (just a one time thing) . This initial time load will look like CE has frozen

As for why your system does this not sure. check the environment n or it could be a firewall blocking it connecting

[MarcRené]

Ah I see... my environment variables contain a "_NT_SYMBOL_PATH"
pointing to msdl from M$.

removed the variable. Result: no delay in GUI.

Nice

[Laphicet Crowe]

[Dark Byte]

It's possible you've already downloaded some .pdb files that are in the default search location, so CE uses them

As for the table causing a freeze, does your table use symbols that are sometimes not available (e.g registersymbol)? Because on initial load while not all symbols have been enumerated, and a symbol is being looked up, it will scan the PDB's for that symbol, interrupting the enumeration until the search is done. If this is done in a loop (e.g display refresh) it can end up freezing CE for quite a long time (until the enumeration stops, but that gets interrupted by the search)
I'll see if I can add in a notification/disable for that when it happens in the main thread

what you can do is delete the PDB's it finds or make sure there is no path anywhere to them.
Or, before opening the table, go to memoryview->file and choose "Set symbol search path" and enter an empty folder

[Laphicet Crowe]

Well, putting a lone ';' in the path fixed it. Thanks!

Still don't know why, even when I did let it populate symbol path, that it still locked despite not retrieving any more PDBs. Oh well.

[Dark Byte]

It likely wasn't locking up, but your table might have hold some undefined addresses in the list
When an address can't be found in any of the local locations, and the symbol files are still being parsed in the background to a local faster system, the PDB files will be scanned instead using the windows API for that, which can be quite slow at times. And because specialized PDB lookups take priority over the background PDB enum, constantly querying the symbol will almost halt the enum.

Next version memoryrecords won't fall back on PDB lookups when the symbol lookup fails, they will just fail (AA scripts will still do PDB searches if needed)
And there will be a dialog that shows after 2 seconds of freezing where you can tell what to do when it takes too long

[Laphicet Crowe]

Sounds good. Also realised I have to re-input the ; into symbol lookup in memory view every time I run CE. I tried looking at registry values to see if I could disable the lookup, but no luck.