I now have version 2.1.4 available for download. Still no automatic update as I consider this to be a pretty unstable release since RDP 6.1 hasn't been burned in enough in RD Tabs.

An early 2.1.3 installer had a big bug in it and it may not let you uninstall RD Tabs on Vista machines. To fix this, use RegEdit to remove a registry key (the installation information for RD Tabs).

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products contains all the applications installed on your computer. Search for the key who has a value called "ProductName" that reads "RD Tabs" and then delete the entire key. On my system, it was called 3F9981A62AC525B45A763E9FFABE3DE3, but this may be different from system to system (I'm not sure). BE VERY CAREFUL while using RegEdit. You can cause serious damage to your system if you mess with the wrong settings.

It is only necessary to mess with the registry if RD Tabs 2.1.4 will not install or 2.1.3 will not UNinstall.

Version 2.1.4 fixes a bug with the "Connect to console" checkbox and also fixes post-SP1 issues dealing with scanning a server's remote desktop sessions in the Remote Computer Information tool. Remote Computer Information is also now UAC-aware.

If anybody has Vista boxes they can disable UAC on to test all this, that'd be great. I can't disable UAC by corporate policy at my Vista box (which is at work). So I can't test that...

Again, many thanks for testing these early Alpha versions.

Links!

x86: http://www.avianwaves.co...-DO_NOT_REDISTRIBUTE.msi 
x64: http://www.avianwaves.co...-DO_NOT_REDISTRIBUTE.msi 

And the changelog...

- The remote sessions in Remote Computer Information was (and is) experiencing issues in Vista SP1 with UAC enabled. Apparently the API doesn't like to be called "too often" so I had to insert a mandatory delay to allow whatever clean-up it's doing before enumerating the remote sessions. Secondly, in regard to UAC specifically, RD Tabs will no longer query remote servers UNLESS you are already elevated. This prevents another problem where even after elevation, it will still give you an "access is denied" error until you quit and restart RD Tabs. I have no idea why this is happening. I can't trace what call is returning access is denied. It SHOULD NOT, but it is sometimes. This problem is intermittent. The new workarounds work reasonably well enough that I'm calling this fixed unless I hear otherwise. You can disable the timing workaround by modifing rdrci.exe.config (under Program Files) and setting EnableSessionScanCleanupDelay to False. DO THIS AT YOUR OWN RISK.
- Because of the above intermittent problem, Remote Computer Information is now it's own EXE (rdrci.exe) and can be invoked from the command line. It will require elevation when run this way if UAC is enabled under Vista. The argument format is as follows: rdrci.exe <Computer> <RDP port>.
- Fixed "Connect to console" bug. The 6.1 API no longer supports "Connect to console" but has a replacement mode called "admin session." On Server 2003 and lower, it works exactly the same as "console session" but on Server 2008, there are changes to the behavior. See the following for details: http://msdn2.microsoft.c...us/library/bb892064.aspx  . Until this version, RD Tabs did not recognize the new API call. Now it will automatically call the correct API setting, depending on what version of RDP is on your system.
- The "Connect to console" checkbox text has been changed to "Use console / admin session" to reflect changes in RDP 6.1 and Server 2008 (above).

I can confirm the Console mode working perfectly now in Vista SP1 - thank you very much.

Nice music btw.

I'm (still) having a problem. The controlbox (where you can minimize, maximize and close the application in the upper-right corner) freezes the system for a couple of seconds, on either of these commands...

Iskander - I'm not following... When does the controlbox freeze?

The only delay issue I know of is with RDP 6.1, the Microsoft portion of the library hangs for a second if you are not connected to any remote desktops (about 1 second). It's annoying, but I can't work around it because this delay blocks ALL threads in the application. I honestly have no idea why. A slew of registry access happens during the delay (thousands), but why registry accesses would block every thread of the hosting application is a complete mystery to me.

Hi Timothy,

Sorry for not replying sooner, but I didn't see that a response was posted...

I get the freeze whenever I click on one of the three buttons in the controlbox, anytime....

Unfortunately, I can't replicate the issue on any of my test machines. 😞 Can you replicate it elsewhere? It might be specific to that computer.

I'll see if a complete de-installation with crapclean and re-install will fix the problem... I'll post back.

Re-install doesn't work. However, when I install the stable version (2.0.13) I do not have the problem. 2.1.14 on a different computer has yet to be tested...

That is really quite peculiar. Control box operations are instantly responsive on all my test machines. The fact that 2.0.13 works fine makes this even weirder. If anything, 2.1.x versions should be more responsive, not less, because I've moved some work into separate threads from the main thread, so that should block the UI less than before.

My only thought so far is that all test versions are compiled in "debug" mode, so I can get more details in the error reports (this can theoretically cause RD Tabs to run a bit slower). Maybe there's something in debug mode that's hanging just on your computer. Fire me an email and I'll shoot you a copy compiled in "release" mode and let me know if it's any different. Go to the contact page (in the top menu of the website) to email me.

Dosent work/run at all for me on Vista x64 SP1.

Have filled in the online debug screen that pops up. Removed for now...... Is there anything I can test ?

Cheers

K

Dosent work/run at all for me on Vista x64 SP1.

Have filled in the online debug screen that pops up. Removed for now...... Is there anything I can test ?

Cheers

K

Crap. I don't have a Vista x64 SP1 box to test, only a Vista 32 SP1 box. Email me (use the contact form up at the top of the page). We'll figure this out.

Kevster555 - based on the error report, I created a build with breadcrumbs in it where it failed so I can see better what's going on. When I get your email, I'll email it to you. Thanks a lot for the help.

Just a preliminary analysis seems to indicate that it IS detecting RDP 6.1, but then when it attempts to initialize it, it's acting like it's NOT 6.1. Very, very odd...

Kevster555 - I just installed Vista 64 and SP1 on my VMWare Server (didn't know it supported 64bit, cool). Anyway, RD Tabs 64 2.1.4 installs correctly on this system.

I have a feeling that somehow your Remote Desktop control may not be registered correctly.

Try running regsvr32 mstscax.dll from an administrative command prompt. Let me know if that helps. If it DOES, I will try to put an automatic fix (automatic regsvr32) into RD Tabs 2.1 before release.

Fire me an email and I'll shoot you a copy compiled in "release" mode and let me know if it's any different. Go to the contact page (in the top menu of the website) to email me.

Hi Timothy,

I've send you an e-mail last week. Did you receive it? Topic was, I believe, the same as the topic of this thread and then some...

Kevster555 - I just installed Vista 64 and SP1 on my VMWare Server (didn't know it supported 64bit, cool). Anyway, RD Tabs 64 2.1.4 installs correctly on this system.

I have a feeling that somehow your Remote Desktop control may not be registered correctly.

Try running regsvr32 mstscax.dll from an administrative command prompt. Let me know if that helps. If it DOES, I will try to put an automatic fix (automatic regsvr32) into RD Tabs 2.1 before release.

Tim

Ill try that later today and let you know.

Thanks

Iskander - I did receive your email and replied with a 4MB attachment that contained RD Tabs 2.1.5 (pre-release) compiled in "release" mode. Did you never receive the reply? I never received a bounce back...

Hi Timothy,

I stand corrected. Has been put into the spam-folder. Just found it and will test it.
I'll get back to you...

Hi Timothy,

Same problem on my own machine. On another machine, however, there is no problem.
One of the differences is that theming is enabled on mine, and not the other machine. And the Windows XP-language is different, as well as that I have VS2005/2008 installed on mine.

What type of theming? Is it a third party app like WindowBlinds or do you just mean the normal XP Luna theme?

So when you say "same problem on my own machine" do you mean you have two machines now where it does this? That could be good in figuring out what exactly is the underlying cause...

I can create a build that creates a log file that writes timestamps after each step when a controlbox message is received. Maybe we can figure out from that what part is hanging.

It does the problem on Minimize, Maximize/Restore, AND the Close (X) button with approximately an equal amount of delay?

Sorry, no, single machine with the problem. Yesterday I had servicedesk-duty and had some time to install some versions of RDTabs on that computer.

And it does with all controls in the controlbox for, as far as I can tell, the same amount of delay for each of them.

[edit] And theming is the standard XP Luna (or Royale, certified MS-theme) [/edit]