Only winvnc.exe and vncviewer.exe changed.There was a nasty part in the code that could crash iexplorer and possible is responsible for otherstrange behaviour. Please use this versions before reporting a bug.

Two suggestions:Firstly, would it be possible for you to avoid releasing test versions packaged in setup exe's, limiting yourself to producing packages only for stable releases? I get the impression that the majority of UltraVNC users are capable of unpacking ZIP files directly replacing previous binaries; only the technically adept are likely to go for these 'bleeding edge' versions anyhow. I understand that you want to limit the amount of forum help you need to give when novice users make installation mistakes, but you should let other forum users take care of that!

Secondly, I'm good with MSDOS batch scripts so if I can build you a (configurable) script to take care of version checking and other automation, I'd be happy to help!

Can you pm the ultravnc.ini ( without passwd) so we can do identical tests.

I tried to repeat it on a vmware with xp installed, but winvnc.exe cpu stayed around 5-20%.Tested with and without hooks.Was it the winvnc.exe with a high cpu ? Normal winvnc monitor himself and slowdown update speedwhen cpu reach 40%.It's possible that the new presets use more cpu ( auto capture alpha blending when semi transparent is supported), but 100%looks like a loop.

Rudi De Vos wrote:Can you pm the ultravnc.ini ( without passwd) so we can do identical tests.

it's done

Rudi De Vos wrote:I tried to repeat it on a vmware with xp installed, but winvnc.exe cpu stayed around 5-20%.Tested with and without hooks.Was it the winvnc.exe with a high cpu ? Normal winvnc monitor himself and slowdown update speedwhen cpu reach 40%.It's possible that the new presets use more cpu ( auto capture alpha blending when semi transparent is supported), but 100%looks like a loop.

To be precise, it's not winvnc.exe process what use 100 %, but the global CPU usage that growup to 100 %.So it's can be interactions with another process, but taskmgr use more with 1.1.9.6 that in 1.1.9.3.The system is clearly slow with simple 4 opened windows of explorer.

Tested with your settings...but can't repeat it.Tested with a single and multi core XP.In one case i had a 100% cpu, but even after closing uvnc it was still 100%.high svchost process wich i could trace to an update that was running.

Most people had an issue with 1993 because the fast inputthread switching.Theoretical this should use mor cpu... but with so many hardware and video cardsperformance is unpredictable.

Conclusions:Switching encoding made no significant difference to CPU usage, just memory - entirely consistent with screen size and encoding methodWindows 7 DWM process isn't pleased about being used in this way. Switching to RemoveAero=1 kills DWM usage to 0% but increases UVNC server usage by a relatively small amountIntel-based chipsets / video chips under XP perform in an inconsistent manner, but still within the bounds of usabilityT

It's hard to test encoders this way. A frame ( time to encode + time to encrypt + time to send data + time to decrypt + time to decode)Using encryption,hextile ( 1% cpu) + encryption (5%)zrle (5% cpu) + encryption (1%)The better you compress the less data need to be encrypted and sended.

VNC try to generate the mosts FPS. If an encoder is faster, it generate more FPS.If the viewer has processed an update, he ask for the next one. ( viewer pulled speed)Perhaps i need add some FPS indication in the status window,it's hard to compare encoders with different speeds.

On idle screens, we slowly decrease the polling frequency and force an update every X seconds.Spikes could be caused by the forced update on idle.

DWM: To see if the screen changed we need to scan for changes, this is done by copying video to system memory.This is done several times a second and sometimes cause wdm to go in overdrive.

To give a short positive feedback: With 1.1.9.6 our refresh problems are better. The first time since win8 changes the things are getting better and not worse (for us, don't misunderstand it please. We really really appreciate your work). We have a reference server (at customers side) were we normally have to refresh the screen manually. Refresh problems are already there with 1.1.9.6, but much more better. Some changes are recognized after up to 6 seconds, but they are recognized.

The Inno Setup x64 version (ultravnc 1196 x64 setup) is labelled as "1.1.9.3" (though the installer executable is different than the previous 1.1.9.3).After installation, the Viewer's version is 1.1.9.1 (it was correctly 1.1.9.3 with the previous version).

Only winvnc.exe and vncviewer.exe changed.There was a nasty part in the code that could crash iexplorer and possible is responsible for otherstrange behaviour. Please use this versions before reporting a bug.

I have installed ChunkVNC_3_3_1 . When i use compiler.exe and create exe files it gives error like

---------------------------WinVNC Warning---------------------------WARNING : Running WinVNC without setting a password is a dangerous security risk!Until you set a password, WinVNC will not accept incoming connections.---------------------------OK ---------------------------

I have replaced winvnc.exe of old version with latest version 1.1.9.6 in application path of ChunkVNC_3_3_1 . Why this error comes when compiling using comiler.exe. in compiler.exe i have filled WAN,viewer,server port and Instantsupport password properly while using compiler.exe.So please help me