Tag Archives: Windows 7

Windows 7 failing to copy large files through network

I have faced problems copying large files (several hundreds megs) over a Windows Network between two Windows 7 boxes. During the copy, the process just freeze forever, and when trying to cancel it, it just tries forever without success.

At first I tough it was a antivirus/firewall issue, but disabling the software on both machines didn’t fix the problem. What really helped was this fix, that disables a feature called Auto-Tuning. It only takes one command on the Command Prompt (Start/Run: cmd) to bring it down:

netsh int tcp set global autotuninglevel=disabled

Then, restart the machine and voila, the problem should be gone.

If this does not fix your problem and want to re-enable this feature, just run:

netsh int tcp set global autotuninglevel=normal

Fixing WMI Service (root\cimv2 namespace missing)

I was working on a VBScript code that uses the Windows Management Instrumentation (WMI) to query the running processes on the local machine, something like this:

strComputer = "."
strProcess2Kill = "something.exe"
 
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcess = objWMIService.ExecQuery("Select * from Win32_Process Where Name = " & strProcess2Kill)
 
For Each objProcess In colProcess
	'Now we will each one of the running processes "something.exe"
	objProcess.Terminate()
Next

This code works in, at least, Win2k, WinXP, WinVista and Win7 (not sure if works on WinNt 4). The problem I had (as you can see here) was that the box where it should have been deployed (Win2k) showed an 0x8004100E error (Namespace specified cannot be found) on the 4th line of the code.

When I ran the following script to query all the namespaces on root:

strComputer = "."
 
Set objSWbemServices = GetObject("winmgmts:\\" & strComputer & "\root")
Set colNameSpaces = objSwbemServices.InstancesOf("__NAMESPACE")
 
For Each objNameSpace In colNameSpaces
 Wscript.Echo objNameSpace.Name
Next

I got this:

DEFAULT
SECURITY
WMI
directory
aspnet

As you can see, the CIMV2 namespace was not present and it should have been. So, something was wrong with the WMI installation on that box.

Then, I ran a very nice tool called wmidiag.vbs (pointed by user Uros Calakovic on my StackOverflow question) to diagnose several problems with WMI. Unfortunately, the tool gave me the same error and no proposed solution. He also mention a couple of interesting screencasts that more than one may find useful.

At the end, Google gave me the final answer once again. Reinstalling the WMI into the Windows Registry and rebuilding the WMI Repository did the trick (I did both, but maybe only the Repository rebuilding helped me this time).

In any case, to rebuild the WMI Repository, these are the only required steps:

  • Stop the WMI service (net stop winmgmt)
  • Go to %windows%/system32/wbem (in my win2k, winnt, on XP would be windows)
  • Rename or remove the repository directory
  • Start the WMI service again (net start winmgmt)

And for reinstalling WMI, you should run these commands on a console:

winmgmt /clearadap
winmgmt /kill
winmgmt /unregserver
winmgmt /regserver
winmgmt /resyncperf

Windows 7 bug affecting Subversion

There is a bug on Windows 7 (and Windows Server 2008 R2) that relates to corrupted files error messages and affects several SVN’s operations (like commit and update). The detailed error message you can get is something similar to:

svn: Can't move '[repo]\.svn\tmp\entries' to '[repo]\.svn\entries': The file or directory is corrupted and unreadable.

And you can even get a Windows error message telling you about a corrupted file.

As I found in here and here, there is nothing to be afraid of, it is just another bug/error on Windows that is going to be fixed on SP1 (but there is already a hotfix ready to install). I haven’t finished test it myself (just missing the restart after the hotfix installation).

The hotfix’s download requires you to give your email address to Microsoft before they send you the link where you can download it (some way annoying). I have uploaded on my own server to avoid the process if I need it again, so you can get it from here if you want (remember that you should NOT download executables from non-trusted sources as they can contain viruses and harm your computer).

Reinstalar Grub luego de instalar Windows

Luego de haber instalado Windows 7 hace algunos meses, en un equipo donde tenía tanto el Windows XP como Ubuntu 9.04, quedó inaccesible este último. Esto debido a que el instalador de Windows no reconoce otro sistema operativo que no sea propio de Microsoft (a diferencia de Linux).

Se debe tomar en cuenta NO utilizar el Live CD de Ubuntu 9.10 para restaurar el Grub de las versiones anteriores de Ubuntu. Esto debido a que Ubuntu 9.10 y posteriores utilizan Grub2, que difiere mucho de la primera versión.

Lo primero que se debe hacer es iniciar la máquina con algún Live CD de Linux (como el de Ubuntu, que es el que utilicé en el proceso).

Una vez que está funcionando, abrimos un terminal. Vamos a necesitar los privilegios del root, por lo que lo más práctico sería ir al shell respectivo:

sudo -i

Luego, creamos un punto de montaje para la partición de Ubuntu:

mkdir /mnt/linux

Después, montamos la partición:

mount /dev/sda2 /mnt/linux

Donde sda2 (sd porque es un disco SATA, a por ser el primer disco duro, y 2 por ser el número de la partición) es la partición donde se encuentra Ubuntu. Si no estamos seguros de cual es la partición, podemos usar el programa GParted (visual) o el comando:

fdisk -l

Una vez que está montada la partición, podemos corroborar que sea la partición listando los archivos en ella:

ls -la /mnt/linux
ls -la /mnt/linux/boot

Luego de que estamos seguros que es la partición correcta, pasamos a reinstalar el Grub mediante el siguiente comando:

grub-install --root-directory=/mnt/linux /dev/sda

En caso aparezca algún error o advertencia, podemos probar el siguiente comando:

grub-install --root-directory=/mnt/linux /dev/sda --recheck

Donde sda hace referencia al disco (usualmente el primario) cuyo MBR será utilizado para instalar el Grub (ojo que NO incluye el número de partición).

Reiniciamos y deberíamos ver ya el menú de booteo del Grub.

Vía: Ubuntu Documentation