On re-boot Procguard.exe (GUI) would not run, no error messages from windows. I disabled windows (hardware) DEP and all o.k. Have re-enabled DEP with Procguard.exe as exception and o.k up to now. Have been running the full version of 3.15 for some time, so will have to check on the changes/updates.
I have DEP fully disabled too so couldn't be sure of compatibility but once PG is set up it should always be transparent until things CHANGE A lot of changes in the newest versions are under the hood, correcting many little issues and adding more protection. Self protection is further increased, for example
This appears only a problem with hardware DEP. Have been running 3.3b without problems for a couple of days, so have now installed on my son`s computer (software DEP) with no problems. Thank you for adding "Ignore checksum changes", this is a nice addition for the ever changing .exe files of my son`s on-line games.
manzz, if you're not seeing the GUI then try deleting (or moving) the pguard.dat and pghash.dat files from \Windows\system32\ (you may need to do this from Windows Safe Mode). If that fixes the problem then that should rule out DEP as being the culprit, so please let us know your findings, thanks Best regards, Wayne
Wayne, I disabled PG protection, booted to safe mode and removed pghash.dat and pguard.dat from \\system32. I then removed PG GUI from DEP exception and re-booted. The GUI did not load.......on checking \\system32... pguard.dat (0kb) had been created. Best Regards
Thanks for that, hmm, interesting. Have you tried deleting the .dat files and then doing a fresh install? If that also fails then it could indeed be a DEP-related issue.
DEP has 3 settings, best edited manually. In the system boot drive, make BOOT.INI not read only, then open it. MAKE A BACKUP FIRST If you choose the following options, then you should follow my guidelines. noexecute=alwaysoff - this requires no changes, DEP is fully disabled for all programs and all Windows services. Can be used well, but best not to use this setting for security reasons. noexecute=optin - this is the default setting. No changes required, just use PG as normal. Windows applies DEP to its services and nothing else unless specified. noexecute=optout - the strongest setting. See my screenshot for how you should configure PG so the GUI will start. Warning do not edit anything except the highlighted command /NOEXECUTE=
Gavin, Yes, thanks,..... but I had done this before my first post in this thread, I made the post to inform of the problem. (I have the GUI by DEP exception) Wayne, To check I did not have other possible conflicts, I installed PG onto a Base install of XPsp2 (no chipset/hardware drivers) with hardware DEP....No GUI. on re-boot.
So that is why I have had no problem on my SP1 machine with 3.2, even when carrying over settings from 3.15 ... I had (hardware) DEP on its default setting! I wonder how many people who had the no GUI problem in 3.2 had hardware DEP turned on fully?
We've isolated and fixed a problem in regards to DEP, it was actually one of the settings on one of the programs used to compress ProcessGuard - a memory integrity option which unfortunately doesn't seem to like DEP at all (we've never had any problems with it before - it's clearly a DEP-related problem). No problems - we've turned that option off, and we'll release a second beta soon. I've also contacted the developer of the compressor to see what his thoughts are on the problem, although I suspect that this option may simply be incompatible with DEP due to the nature of DEP protection.
Really? My bad then, as i have upgraded to SP2 very recently and have only bothered to check what setting i had today. Nevertheless, 3.2 worked fine when it was still SP1
The author of the compressor got back to me very quickly and has already isolated and corrected a bug that was probably the culprit, based on my findings I handed over to him. He has already released a new beta for me to test so I'll be going through that today, so hopefully this fix should allow us to continue using the memory integrity option that was triggering the problem. [Edit] - Yep, looks like it's fixed.
Well worked, I only posted due to the fact that windows DEP did not report stopping the GUI (but it did). Hope I did not cause too much fuss/recoding. Regards
True, when it blocks something it usually warns and lets you click to access the settings. I guess this is due to the bug being in the packer code itself (not something in the application) causing DEP to go off. Thanks manzz, we solved a couple of mysteries at the same time !
