Windows Permissions Identifier(cheker.exe)

[MacQibble]

Hi.

No idea when this fault started, but my StationX File Permissions program cheker.exe won't run?

Uninstalled and reinstalled. No joy. The only change i can think of since i last ran it is my SP1 update for Win7.

Or maybe the recent AvastFree upgrade with its new auto-sandbox... but that should ask and I've excepted the StationX program folder anyway.

Never had a program just refuse to launch like this. Werfault shows a crash report but i can't read that stuff.

Compatibility testing for Vista (it worked in Win7 x64 but what the..) first said cheker.exe was incompatible but then gave the UAC prompt that cheker.exe was asking for permission to run. Gave it permission and it refused to show.

Comodo's Defense+ was happy to run it before and isn't sanboxing it, so I'm stumped.

[MrBrian]

I'm not sure, but you could try AccessChk (elevated) instead.

[MacQibble]

Hi.

Couldn't let go of cheker.exe without a fight. The event log shows the error code as 0xC0000005, which I found is to do with:

"an illegal "memory access violation". This can be caused by anything from faulty RAM, an incorrect/corrupt device driver, poorly written/updated software and more commonly ... malware/adware installations."

Personally, I don't jump to think everything is malware and WPI only failed to open after SP1. So did my Windows Mail because that needs a reg tweak to defeat Windows 7 and i had to reinstate the tweak.

I use EMET for DEP etc, and have System Status settings as:

DEP - Always On
SEHOP - Application Opt Out
ASLR - Application Opt In

Didn't think i should reduce the DEP setting so had the warped idea i could add cheker.exe and pcheker.exe to EMET and just untick DEP for them, but that didn't fool anyone.

Why would one little program stop working like this? (I read here on Wilders that AccessChk might not be as thorough (like I would know the difference ... but it's the learning that matters ).

[MrBrian]

Originally Posted by MacQibble

(I read here on Wilders that AccessChk might not be as thorough (like I would know the difference ... but it's the learning that matters ).

AccessChk pre v5.0 had a bug which I reported and was fixed in v5.0. If you run AccessChk elevated, it should be fine to use.

[sbseven]

Originally Posted by MacQibble

I use EMET for DEP etc, and have System Status settings as:

DEP - Always On
SEHOP - Application Opt Out
ASLR - Application Opt In

Didn't think i should reduce the DEP setting so had the warped idea i could add cheker.exe and pcheker.exe to EMET and just untick DEP for them, but that didn't fool anyone.

"DEP - Always on" can't be overriden as you've found out. If you want to test whether DEP is responsible, set DEP - Application Opt Out, reboot and then add checker.exe and pchecker.exe as exceptions: http://www.trishtech.com/winvista/cr...dows_vista.php

"DEP - Application Opt Out" implies DEP is on for everything except what you explicitly exclude.

FYI, I've an application that fails under DEP, but I get a ballon message stating DEP closed the application, so it's perhaps obvious if DEP were responsbile?

[MacQibble]

Originally Posted by MrBrian

If you run AccessChk elevated, it should be fine to use.

You are scholar, sir. Also run AccessEnum. Many questions filling aging braincell now.

@sbseven:
Thanks for advice. Not the only victim of SP1 and DEP. Presumably somebody tightened a noose? Mind you, it's just the event log error code I'm going by, and the timing of the onset of crashes, that makes me link SP1 and DEP. Don't receive any balloons. A mystery to add to many.

[MacQibble]

Originally Posted by sbseven

If you want to test whether DEP is responsible, set DEP - Application Opt Out, reboot and then add checker.exe and pchecker.exe as exceptions

I hot-foot back to say I did as advised and Windows Permissions Identifier has returneth! Joy and hollerin' in the homestead.

It's the simple solutions that defeat me.

Thanks.