I am starting to upgrade some of my client machines to Windows 10 and they are reporting that the screen redraws in AREV32 are much slower than before.

Is there anything I can do to remedy this?

Thanks

How much slower. From blink to 3 blinks, or you can count the seconds as it forms?

Been using Arev32 and Windows 10 for years and they don't seem slow.

Dave

Try excluding your .LK & .OV files from your antivirus software.

Robert Catalano | Revelation Software

Director of Sales

99 Kinderkamack Road | First Floor | Westwood, NJ 07675 USA

V: +1 800.262.4747 | F: +1 201.722.9815

[email protected] | www.revelation.com

Hi all, thanks for the replies.

OINSIGHT is used over a network drive in our standard use case, but I've also tested it on my local desktop machine with no improvement in performance. I also checked the Network tab on the Performance Monitor, and both W10 and W7 have the same network throughput performance (bytes/s) while using the application.

So I think I can safely rule out a TCP stack configuration or other network performance issue.

I've timed a 1 second delay on average between Win10 and Win7. It happens on input window draws & popups. Not necessarily on menu draws.

It seems pedantic, I know, but it is noticeable, and I am getting complaints about it.

These users will also sometimes receive a "CHECK_TIME is an unrecognized word" error in AREV, followed by SYS1000 Error loading program: "DEBUGGER", which then crashes the app.

I don't know if this is related or not.

Neither OS is running any additional AV software beyond whatever is built-in from Microsoft.

Any further insight would be greatly appreciated! Please let me know if there is other information I can provide, thank you.

Hi Joe,

<Neither OS is running any additional AV software beyond whatever is built-in from Microsoft. >

- so did you set an exclude of *.lK and *.OV files in Microsoft Defender?

and what is the workstation RAM memory? 8 Gb?

Richard

Richard - affirmative. Did not notice any improvement.

The workstations in question have 4 GB RAM.

I threw in another stick to test with 8 GB and the performance remains unchanged.

I have found a solution - by running OINSIGHT as Administrator.

»I have found a solution - by running OINSIGHT as Administrator.

Which could have let it register something.

Try again, but this time not as admin.

Excellent point Barry, but sadly reverting to non-Admin causes the slowness again.

I have seen some workarounds using the 'runas' command and supplying Admin credentials, but this is a huge security hole, and I will have to figure out some other method.

So I have been digging around on this for a bit with no solution (yet!)

I have been using a couple tools: Process Monitor, Process Explorer, LUA Buglight, Compatibility Administrator and Standard User Analyzer. They either show the resources required (REGKEYS/file paths,etc) or allow you to modify compatibility.

I haven't been able to pinpoint anything solid yet. My current thoughts are something printer related or something GDI+ related, based on some of the DLLs I'm seeing used.

One thing of interest is *how* the program is run as Admin.

If I right-click and use the context option "Run as administrator", I get the unwanted UAC prompt, but once elevated, the program performs perfect.

If I right-click, go to Properties → Compatibility tab and check "Run this program as an administrator", I do not get the UAC prompt, but the program does get elevated permissions.

I can confirm that the program is receiving different permissions using Process Explorer.

When run as Administrator - in either scenario, I can see that an Environment variable __COMPAT_LAYER is set to "Installer". This variable doesn't appear when run as regular user.

This means to me that it's not just the compatibility level, there is an additional *something* that is enabled when using the right-click context option.

Since it's seems like the screen redraws are slow when the program window is maximized, could it really be something .NET/GDI+ related?

View this thread on the Works forum...