Author Topic: [SOLVED] ManageACL_32.exe crash - illegal instruction (Read 16558 times)

RainyShadow · « **on:** October 02, 2016, 12:37:30 pm »

Just recently updated Windows Repair to the latest version, and now i get dozens of crashes while running repairs.
I believe ManageACL_32.exe is compiled with some optimisations that are not supported by my AthlonXP CPU ( does it use SSE2/3/4? )
You can find a crash log in the attachment.

Boggin · « **Reply #1 on:** October 03, 2016, 04:40:56 am »

I've passed this onto Shane but at the moment he's extremely busy with work coming in from his computer repair business, so not sure when you will get an answer.

Shane · « **Reply #2 on:** October 03, 2016, 05:06:06 pm »

I dont have any of those set, but I checked and looks like sse2 is default
https://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx?f=255&MSPPError=-2147217396

Quote

/arch:SSE2

Enables the use of SSE2 instructions. This is the default instruction on x86 platforms if no /arch option is specified.

Which as of right now I have none set.

Shane

RainyShadow · « **Reply #3 on:** October 03, 2016, 08:29:24 pm »

So, (hopefully) the next release should work fine?

Shane · « **Reply #4 on:** October 04, 2016, 01:55:59 pm »

I dont have an old athlon to test on, so not sure what the best compile setting to use.

I wonder if /arch:SSE would do the trick and also if there would be any speed difference between them.

Shane

RainyShadow · « **Reply #5 on:** October 04, 2016, 06:48:50 pm »

SSE should be fine, i guess. Even my old Pentium 3 based laptop supports this

About the speed, i think launching the executable would take much longer than the procesing itself, so don't worry about that.

If you make any test builds, i can check them.

Shane · « **Reply #6 on:** October 05, 2016, 10:32:27 am »

Well since it is just a recompile setting lets give it a try. Updated both manageacl exes to v1.4.0

The 32 bit one I actually set to no enhanced instruction set. Since SSE is suppose to be used to speed up float values I checked and I am not using any float values, so lets see how it does.

The 64bit version doesn't have that compile option and so isnt any different, I just dont know why the exe was bigger on the compile, perhaps because I updated visual studio and so some of the header files must have changed.

But since they are bigger and so something has changed I need to test to make sure they work like they should. I have xp in vmware I will test the 32 bit one on and compare the speed on the old comple to see if there is any change, good or bad. Then I will test in the 64 bit oses and make sure it still works like normal

So here is how you will do this, grab the two new files I attached and put them in the files folder of the program replacing the ones already there.
Then in the main program folder open the file_list.txt file and remove the two entries in there for the two exes. That file list isnt to stop users from using modified files, it is only there because I have had some of the files end up on bad sectors and be corrupt or antiviruses remove them, and then the repairs get screwed up. So the program simply does a file check at start up to make sure they didnt get corrupted or missing.

Let me know if that fixes the crash for and if it does and my test shows the exes work like they should they will be in the next update

Shane

Shane · « **Reply #7 on:** October 05, 2016, 01:52:48 pm »

Test results.

vmware, windows xp 32 bit. After each test I restored the vmware image back and so each one ran under the identical conditions.

XP - total repair time - 05:27 - No enhanced instruction set
XP - total repair time - 05:36 - SSE2
XP - total repair time - 05:34 - SSE

And each one set the permissions and worked correctly.

Shane

RainyShadow · « **Reply #8 on:** October 05, 2016, 09:12:15 pm »

With these files it works without crashes now, thanks.
I'll check the new version tonight when i get back from work.

RainyShadow · « **Reply #9 on:** October 06, 2016, 11:02:48 am »

Quote from: RainyShadow on October 04, 2016, 06:48:50 pm

About the speed, i think launching the executable would take much longer than the procesing itself, so don't worry about that.

OK, Maybe i was wrong about the speed. I thought ManageACL is used for registry permissions only, but now it's been working on my C: drive for about 20 minutes and counting... HDD I/O speed is the limiting factor there.
Funny, how in your test the more optimisation you set - the slower it went

The 3.9.12 version of WR still crashed with the stock executables, but after replacing them it seems to work fine.

[EDIT] hmm, it seems to get confused by junction points :