Win 7 slow file copying to network drive - is it Win7 problem?

I was backing up files using RoboCopy from my Win7 (64-bit) home machine to a network drive mounted on an XP Prof machine and noticed it was awfully slow. A check of the Network Utilization in the Task Manager's Network tab revealed that it was clocking only 2-4% and no one was using the network except me.

When I was reading this thread seeking any solution to my problem, I never believed it was the fault of Win7. Why? When I was doing a similar operation using a Cat5e cable with my laptop, the network utilization was in excess of 98% constantly. Hence I knew it was not Win7, as blamed by the above thread nor my network.

I knew it must be hardware associated with this machine that exhibited the slowness. Thankfully experience told me not to follow the instructions posted on the Internet blindly or else I could end up in a worse shape than I began with.

It turned out the solution was simpler than many would have guessed and it was highly unusual but the signs were always there.

It was a faulty Cat5e that was used to connected this machine to the router. The cable did not exactly not broken. Only the transmit line must be hanging by the thread resulting in slow copy to the server but acceptable performance in copying from the server. What pointed me to this simple solution was the fact that I was using a totally different cable when connecting the laptop to the network.

Windows 7 Ultimate insult to Tablet owners

Sometimes ago, I reported that Microsoft  has decided not to provide tablet recognizers for other languages unless you pay them more money by buying either Ultimate Edition or Enterprise Edition.

The other day, I have the pleasure of using a Tablet running English Windows 7 Home Premium and sadly the pleasure quickly turned sour when I discovered that the TIP was locked into a keyboard when I selected Traditional Chinese. This confirms that Microsoft's early annunciation is true.

On my old P1510 running the trusty XP Tablet edition, I can use the TIP to write TChinese or any other foreign language. Now greedy Microsoft is giving their user an Ultimate insult by forcing them to buy expensive edition so that they can write in foreign language.

No wonder Microsoft is losing market shares on tablet to Apple's iPad as Microsoft's is blinded by chasing money rather than providing their supporters with better support. Now Micro$oft has taken away something that their supporters naturally expect would be in all editions of Windows 7 as they are in XP. Who would have guessed a supposedly 'better' and 'newer' Operating System has fewer supports, unless you pay more? It is just pure greed.

If you are one of those victims of M$ greed and only wanting to write Chinese, by-pass Micro$oft and buy one of this fantastic tool - Penpower Junior. Don't let Microsoft hold you hostage. This tools can be used in Tablet or non-Tablet.

A review of Advanced Registry Optimizer 2010

I have been asked for an opinion of this tool called "Advanced Registry Optimizer 2010" (ARO) from Sammsoft. Since I have never used anything like that despite using Windows since 3.0, I decided to give it a try.

The one so 'generously' made available from its web site was only a nobbled version allowing one to correct up to 100 errors. This wasn't made clear in the download. Anyway, the version I tested was 6.0.743.796 and all tests were performed in two Virtual Machines whose guest OS's were: Windows XP SP3 and Windows 7 Ultimate. Furthermore all tests, other than installations, were carried out in LUA (Limited User Account) and disconnected from the network, just in case the program performs call-home operations.

I also deliberately created a key in HKCR\CLSID with incomplete and incorrect information. While the GUID was correct, the ProgID contained incorrect or missing data. This was to test how good this program was.

Although the installation was relatively straight forward there were two areas that were not very satisfactory:

• The acceptance of askToolbar installation should be a bit more obvious.
• After successful installation, it should not execute an automatic scan without user's instruction. It ran and I had to use tools like Process Explorer to terminate it immediately. Not nice.

As mentioned all runs were carried in LUA and the program was found to be faulty running in this kind of account settings. Since all programs in Windows 7 and Vista run with standard user security token by default, ARO's end result was identical to that running in XP LUA mode.

This observation was substantiated by comparing the run time log captured using Process Monitor when ARO was executed in XP SP3 and Windows 7.

It did not crash when running in LUA. It simply lied to the users telling them their system had fewer issues than it really was.

Take for example, the specially planned registry settings was not identified when ARO was running in LUA. The reason was that it tried to open the registry key HKCR\CLSID\<My-Test-GUID> with Read/Write access and failed due to lack of sufficient rights when executed in LUA.

The program simply swallowed the error and moved on. This was a very bad programming mistake. The return code was very specific of the problem and when the program was told access was denied, it should have immediately ceased processing and informed the user to run with administrative rights.

Instead, the program just treated that as a non-event and moved on. This resulted in a misdiagnosis.

You can easily test this without these tools. Run ARO in LUA and run it again with "As Administrator" and compare the findings. If the program is functioning correctly, it should report identical error. In this version, they differ drastically.

In fact, if you go to the settings and de-select all settings except "ActiveX and COM" and run it. The chance is that you will get a 0 error when running in LUA and non-zero with administrator's rights. This is because when it opens HKCR it demands Read/Write even in scanning mode. This indicates a possible programming error! Perhaps it is an innocent victim of the ATL registry library problem.

As a result, the product is not functioning.

Who creates the ASPNET account in XP?

I have been using a couple of XP VM for development and suddenly I have to develop some ASP.Net. The VMs did not have IIS installed and only has .Net Framework 2 SP2, 3.0, and 3.5 as well as VS2008.

After installing the IIS, I was having trouble to launch some ASP.Net application. Upon some investigation, ASPNET, the default account for IIS 5.1 in XP, was not there!

So who was responsible for creating it?

It turns that one needs to install .Net Framework 1.1 to create that account irrespective if IIS 5.1 is installed or not. What distracted me was the presence of v1.1.4322 sub-directory in the Framework as it turned out it was placed there when I installed .Net Framework 2.0 SP1.

It is not the same as running the installation script for .Net Framework 1.1.

In search of a Backup Utility for Windows 7

While people reading this title may be wondering if I have missed the much touted "Backup and Restore" features in Windows 7 and wondering why I need to search for (better) Backup Utility?

Let me describes the deficiency in Windows 7's "Backup and Restore" utility before I will describe my search result.

Microsoft has succeeded in taking a highly capable program called NTBackup and destroying it for the sake of some eye-candy screen. The Win7 backup is so slooooow that any ZIP program will beat it hands down. Not only that, the eye-candy stuff lacks any really useful progress information. It does not even bother to tell you how many files it has picked up, which file is processing, and the total size of the files being backup (until the whole thing is finished) or expected time to take, given that is a best-guess. Apart from some pretty looking screens, the user-interface is totally unintuitive and functionality lacking.

If you have not seen an industrial strength real back up utility, I suggest you fire up a copy of NTBackup in XP Pro or installed it in Home Edition.

One of the basic needs of a back up utility is to be able to add the back up information to what is already there like keeping revision so that you can go back several generations to restore the data.

Not only that a backup utility is as good as its restoration capability. It has to be able to restore the data accurately and precisely including restoring the original ACLS for the NTFS files and folders. Failure to do that can cause major problem and security risk. Imagine you are backing up the profile areas for a machine and has to do a disaster recovery only to discover that the resulting ACLS are all wrong!

A good backup utility also should ensure that the person running this must be a backup operator or one with the SeBackupPrivilege, to perform backup and SeRestorePrivilege, to perform restoration.

The other features commonly found in industrial strength backup utility is to be able to perform incremental backup so to reduce the backup volume. This is important when you are doing a daily backup.

Armed with these demands, I evaluated the following free backup programs: NTBackup, FBackup, and Comodo Backup.

Sadly only NTBackup managed to perform flawlessly managing to replicate the ACLS perfectly. Here is a screen shot of the source (left hand window) and restored folder's ACLS (right hand window):

I restored the material to a different directory to check the restoration process. As a consequence, NTBackup is being used as a benchmark against which the other utilities are compared.

FBackup4 Version 4.4 Build 207
This is a very simple to use free 'backup' utility. The good part of this one is its ability to manage several backup instructions as jobs in the program. It automatically increments the backup volume file name and the backup volume is in ZIP format. It is relatively fast.

However, it is a naive implementation of a backup utility. At best, it can only be classified as a ZIP program with a purpose-built user-interface.

Here is the screen shot of restoring the user's profile to an alternate location. Once again the left hand window shows the security settings of the original top level user profile folder and the right hand window shows that for the restored materials:

This clears shows the restored materials have fewer privileges than the original materials failing being a competent back up utility. This is a simulation of profile restoration.

Comodo Backup Version 2.2.127000.12
The user-interface is prettier than FBackup but it is also more confusing and functional lacking. With its user-interface, a user cannot workout how to get the program to remember the backup instructions so that one can reuse them again. However there are several ways this program that this program can do that, albeit not as intuitive as that for FBackup.

During the composition of the backup instruction using the wizard, you can use the Schedule definition to remember your instructions even if you do not want to do scheduled backup. You simply change the type to manual backup. Strange logic.

The other way is to export your backup instructions to a file which contains the command-line arguments corresponding to your instructions. With this file you can then use the /script command-line directive to supply the script file when launching the backup utility.

This utility has some slick facility allowing you to define the backup volume file format - such as including date, time etc. They call them macros and they are not available in FBackup. It also has facility for you to define the level of compression you want during backup.

Performance of this program is very good. However it suffers the same problem as in FBackup when it fails to reproduce precisely the ACLS as shown below:

Conclusion
These backup utilities are not really backup tools but specialized ZIP programs. It is not just because they are using ZIP format but because they left out the ACLS what they need to use to restore them

While NTBackup is available official in XP Pro and optionally in XP Home Edition, Microsoft has provided a cut-down version of this tool for Vista/Windows 7, called "Windows NT Backup - Restore Utility", so that user can restore from NTBackup volumes.

However, NTBackup has been known to run fine in Vista and in Windows 7 (and here). Since the 'installation' of NTBackup is so low impact, I will definitely give that a try. The big remaining question is: At what time in the future that Windows development will render our trusty friend not operable?

DIR command in XP does not display Chinese correctly in English Windows

This is a very annoy issue I have just come across mistakenly believing XP being a Unicode OS and that its DIR command will display any characters you can create mirroring that in the Windows Explorer.

Such is not the case. While this post discusses issues with the DIR command in XP in handling Chinese characters, the problem applies equally to other languages.

I have a test file like this shown in Windows Explorer:

In CMD the DIR command returns this:

Which is not what I want or expect. So what is the reason behind this? I thought PowerShell being a .Net implementation of a shell can surely handling this. Despite following these advices, it produces the same result as above.

It turns out that the DIR/CMD uses non-Unicode API to display the file name as a result one has to change the "Language for non-unicode programs" in "Regional and Language Options" via the Control Panel to the Chinese code page as follows:

With this setting, the DIR command displays the file name correctly:

Just to prove the point, I then use the chcp command to change the code page to 1252 and this produces the following result:

Which is what we have got before.

While the DIR displays the file name incorrectly, if you starts CMD with the /U switch and you redirect the DIR output to a text file, the content of the text file is in full Unicode and the Chinese file name is displayed in say Notepad correctly.

So the moral of the story is that you must set the "Language for non-Unicode Programs" to the correct code page in order to produce visually correct file name in the DIR. This has no effect on batch file or redirection if you launches the CMD with the /U.

Copying Or Moving Subversion Repositories

Recently, I had to replace the hard drive on which my collection of repositories live. Rather than using the subversion recommended way, I used XCopy to transfer the collection from my old drive to the new in Windows XP, after making sure no one is using the FSFS. I have nearly lost the lot.

The result was corrupted repositories and when I tried to commit files to one, it reported the path to ...\db\transactions\74-24.txn not found and refused to commit. ...\db\transactions was definitely missing.

This is the command with the switches I used:

XCOPY <source> <destination> /h /o /c /v /k /s

It is the last switch /s that was the culprit. It only copies non-empty directories and files. In svn, you can have empty directories (such as db\transactions) and files with zero bytes. As a result, they were not transferred across.

The correct switch is the /e that will copy empty directories and zero-byte files. So to copy them correctly use the following switches:

XCOPY <source> <destination> /h /o /c /v /k /e

There are two methods that I have found to be more reliable and easier to use.
1) Use Windows XP's NTBackup tool
This is the most reliable way of backing up the entire repository and restoring them. It should be used as a matter of course. I am wondering how well the Win7 replacement of this tools works? Vista's one is totally useless.

2) Use 7za.exe
Make sure Windows users use * to specify all files instead of the Windows' *.* convention for all other commands and to include the -r switch.

XP Control Panel Applet does not launch - a solution

I was playing with a Virtual Machine containing a copy of XP SP3 and no matter which user account I was in, I could not launch the applet from the Control Panel. However, I could launch the CPL from command line, for example AppWiz.cpl.

AppWiz.cpl is also an interesting one as one can also supply additional commandline options to support other facility, such as add/remove Windows components. A complete command line looks something like this:

"C:\WINDOWS\system32\rundll32.exe" C:\WINDOWS\system32\shell32.dll,Control_RunDLLAsUser "C:\WINDOWS\system32\appwiz.cpl",Add or Remove Programs

Obviously the cpl files were not corrupted. So I was intrigued and determine to find out why.

I decided to use ProcMon to monitor the operations on the faulty machine, in particular, on the launch operation of Rundll32.exe by Explorer.exe. At the same time, I used the same program to monitor the operations on a machine that was working properly. Then I could find out the reason by patiently comparing the two log file entries.

In the captured log file, I jumped to the "Process Create" entry of Explorer which was responsible for launching the Rundll32.exe process as my starting point. The properties, in particular the command line for Rundll32.exe, immediately gave me the clue. On the faulty machine, there was no command line argument to Rundll32.exe and that explained why double-clicking on a control panel applet did nothing except launching Rundll32.exe and then it immediately terminated itself as nothing to do.

Looking back up the operations sequence, the next clue to look for was the exefile's open command as this was the operation that composed the command line argument to launch an executable such as Rundll32.exe.

This is specified in:

HKCR\exefile\shell\open\command\(Default)

On the working machine, the value was:

"%1" %*

But on the faulty one, it had this:

"%1"

The absence of %*, which meant to append the rest of the command line arguments, explained why the faulty machine did not launch the correct control panel applet as it failed to include any command line argument after the first one, which was Rundll32.exe.

Appending the %* to the exefile's open command fixed the problem.