[SOLVED] Performance/refresh problems with OS less than Win8

[Prisma]

Hello Rudi,

we're packaging the normal winvnc.exe (1.1.8.0) with following components:

winvnc.exe (compiled for win2000+)
vnchooks.dll
schook.dll
w8hook.dll (since 1.1.8.0)
sas.dll

polling options, unchanged for years :

Code: Select all

[poll]
TurboMode=0
PollFullScreen=1
EnableHook=1

During testing 1.1.8.0 we noticed on XP-Win7 a decline of reliability regarding screen refresh. This behaviour against a huge improvement on Win8 machines. This happens not always, but on some installations we have to press the refresh button manually. Using an older winvnc.exe, no such problems. Therefore we are worried about a possible bug introduced with some Win8 changes. What could have happened?

[Rudi De Vos]

You can't compare the win8 hook ( that works like the mirror driver) with the previous hooks.
The effect is the same as comparing a xp hook with the xp version with the mirror driver.

For the XP/win7 issue's
Please test first with 1.1.9.1, i can't do any tests with an older version.

If the mirror driver is installed it isn't used when
-you are not elevated dmin
-run a w32 version on a x64 system .
driver installed but not used -> polling fail and slow as hell

win8
1.1.9.1 is a lot faster then 1.1.8 also on win8.
The best you can see it is using the u2 encoder with a HD video. ( 12 FPS)

There is still a bug in the w8hook that i'm trying to solve. It can crash the server when
you ctrl-alt-del to get the special start screen.

[Prisma]

Good Morning,

it crystal clear, to compare Win8 performance with XP-Win7 performance makes no sense. Other hooks. I'm comparing XP-Win7 with XP-Win7 with 1.1.8.0 and an older version. Yes, a higher frame rate would be nice. But to be forced to press the refresh button means a frame rate of zero To try 1.1.9.1 makes sense anyway.

(We never have used a mirror driver because winvnc.exe is often not elevated. Sometimes we trigger elevation on demand for installing ourself as temporary service.)

But you wrote "driver installed but not used -> polling fail and slow as hell". Hmmm. Sometimes everybody has to deal with concurrent installations. Next time I notice a need of manually refresh I'll look if a foreign admin has installed another (u)VNC with mirror driver.

[Marvin86]

Hello,

I can confirm that we experience the same refresh issues with version 1.1.9.1 when taking over windows 7 systems.
Basically, the screen does NOT refresh, you need to manually refresh it.

We are currently investigating how to fix this problem. So far we found the following commands interesting in resolving the issue:
We didn't play much with these settings yet, but setting Turbomode=1 inmediately fixed the problem that we had a minute before taking over a certain computer. So at the moment, we are testing if this permanently resolves the case of not refreshing properly, or that in some cases the issue still persists.


http://www.uvnc.com/docs/uvnc-server/69 ... ncini.html

[poll]
TurboMode=1
Fast scan screen, some small changes can be missed
PollUnderCursor=0
Poll the window below the cursor
PollForeground=0
Poll the foreground window
PollFullScreen=1
Poll the full screen ( default)
OnlyPollConsole=0
Don't use
OnlyPollOnEvent=1
Bad Updates, only poll screen when mouse/keyboard is used. Minimize Bandwidth.
EnableDriver=0
Use mirror driver when installed
EnableHook=1
Use hookdll when installed
EnableVirtual=0
SingleWindow=0
SingleWindowName=
Current not used

[Rudi De Vos]

Make sure that
OnlyPollOnEvent=1
is never set.

This require a key press or a mouse move for screen updates.
This option is from the time you still used a 56k modem connection.

[Prisma]

We only use the settings noted above. I assume the default of OnlyPollOnEvent is 0. Therefore I'm sure we don't use it.

[Marvin86]

Hello,

I will update the results as we updated the ini files accross our network (3000 PCS). Some of our users don't turn the PC off, and we didnt manually restarted
the unvc_service to load the new settings as we assume(d) most users would atleast reboot their system daily or each few days.

Anyways the result is that we don't have the problem anymore of the screen NOT refreshing at all. There are some issues though when you take over a screen, and you open a CMD prompt and start
typing in it. it takes about 1 or 2 seconds before the letters you typed show up, making it a bit confusing and the user thinking we are slow typers

So, all in all... I'd say the refresh problem is solved (with the setting of Turbo=1), but not ideally yet because its still damn slow in some cases, things that involve typing. but atleast it keeps refreshing.
Only thing left for me to experiment on is simply to start using lesser quality settings as its still set on "AUTO" (Auto select best settings).
And, then there is the selection of different encodes to use. There are quite a bit to choose from:
ZRLE, ZLIB, ZLibHex, Hextile, RRE, Raw, ZYWRLE, Ultra, CoRRe, u2 etc...


Just for the curious, our ini file on certain parts looks like this (if you have better recommendations feel free to tell):

[poll]
TurboMode=1
PollUnderCursor=0
PollForeground=0
PollFullScreen=0
OnlyPollConsole=0
OnlyPollOnEvent=0
MaxCpu=0
EnableDriver=0
EnableHook=0
EnableVirtual=0
SingleWindow=0
SingleWindowName=

[admin]
UseRegistry=0
MSLogonRequired=1
NewMSLogon=0
DebugMode=0
Avilog=0
path=<removed>
DebugLevel=0
DisableTrayIcon=0
LoopbackOnly=0
UseDSMPlugin=0
AllowLoopback=0
AuthRequired=1
ConnectPriority=1
DSMPlugin=
AuthHosts=
DSMPluginConfig=
AllowShutdown=1
AllowProperties=1
AllowEditClients=1
FileTransferEnabled=0
FTUserImpersonation=0
BlankMonitorEnabled=1
BlankInputsOnly=0
DefaultScale=1
CaptureAlphaBlending=1
BlackAlphaBlending=0
primary=1
secondary=0
SocketConnect=1
HTTPConnect=0
XDMCPConnect=0
AutoPortSelect=0
PortNumber=<removed>
HTTPPortNumber=<removed>
IdleTimeout=0
RemoveWallpaper=0
RemoveAero=0
QuerySetting=4
QueryTimeout=15
QueryAccept=0
QueryIfNoLogon=0
InputsEnabled=1
LockSetting=0
LocalInputsDisabled=0
EnableJapInput=0
kickrdp=0
clearconsole=0

[Rudi De Vos]

This is wat i always use.

TurboMode=1
PollFullScreen=1
EnableHook=1

The hook give hints about the changed screen position hints have priority to polling.

The polling check x times / sec for changed pixels, if no changes are found for a few seconds
the polling go in sleeping mode to avoid cpu intensive polling. Once a change is found it it check
fast until screen is back static.

Turbo: If a screen position or some foreground window changed, check it.
It also limit the the pixel check to blocks to makes it polling faster.

[Prisma]

The point is, we never had to set Turbo Mode=1. That's what surprises me.

Normally I would not hesitate to change the setting. However, if we change one bit at our wrapper, some virus scanners will eat him again. The result is that we had to whitelist him again. If Rudi would find a fault and he changes winvnc.exe, we would also have to do this... Anyway... Therefore it would prefer we could reproduce the error to fix it and have a clean solution.

[Rudi De Vos]

TurboMode=1 use less cpu, that's all.

In normal mode you compare all pixels, in turbo mode you compare a raster of pixels.
Each check the raster is moved.

[Prisma]

AAAAAHRG... possibly found the bug:

Background:
For backward compatibly reasons, we repackage uVnc only with 32-bit binaries build for win2000 along with a 32-bit w8hooks.dll (if the target system should be Win8). Following Rudis documentation and our experience this works. But:

While looking at the new 1.1.9.3 binaries I noticed that 3 different schook.dlls are distributed with 3 different filesizes. Cross-checking our lately released binaries and the installer script it seems that we released a schook.dll (137KB) presumably build with a newer version of VS. Will this never work on systems older than Win8? Or are there only dependencies to VC++ redistributables, which could be fullfilled or not?

@Rudi: Is schook.dll responsible for detecting screen updates? Could this be the reason for our "random" problems? Sorry, I thought you deliver always the same schook.dll. The sourcecode of this dll is very old and unchanged for years, isn't it?

[Rudi De Vos]

We build it using 3 compilers
VS2008
VS2010 ( no w2k support)
VS2012 (no w2K/xp support)

No support is not supported, exe fail to start ( unknown kernel functions error....)
I guess that when you load a dll it also fail.
It has nothing todo with the redist, it's a kernel (OS) issue.

vnchook/schook : give hints about the changed regions.
It depend on the applications, some are faster with vnchook and other with schook.
vnchook: Use the system messages to find hints about changed locations
schook: use the accesibility engine for the same
If both are installed, schook is used

On most win7 systems ( who has a very fast video card for aero) polling
is fast enough, you don't need any extra hook. If the hardware is older
the vnchook or schook help to make it faster.

You can use all w2K exe/dll and distribute with the w8hook. This dll is only loaded
when a win8 OS is detected.

There are no dependencies to VC++ redistributables, we compile
all function in the exe to make our dll's and exe redist independed.
Drawback is that we have big size exe and dll's.

[Prisma]

We build it using 3 compilers
I guess that when you load a dll it also fail.

Hmm. We definitely rolled out the wrong schook.dll (no XP support), but at the moment winvnc.exe (win2000 bins) works on XP anyway. Sometimes slow. Possibly you catch this exception on loading the DLL?

You can use all w2K exe/dll and distribute with the w8hook. This dll is only loaded
when a win8 OS is detected.

Good to hear this explicitly.

Sorry again, for the wrong assumption that always the same schook.dll is installed. Therefore I did catch the wrong schook.dll from my local addon installation. Looking directly into the installer (innounp.exe, great tool) showed the failure. I set this thread to solved and open it up again if the problem persists anyway.