On two occasions now I have had Windows 7 SP1 32 bit lock up solid on an attempt to run an installer directly from a network location. Only thing special is that I have disabled UAC on all my systems. Basically, I have a 32 bit VM, and I've downloaded an installer to a location on the host system's hard drive. I navigate to the download location in Windows Explorer (e.g., \\SERVER\SHARE\Download\SomeApplication), then double-click the executable. Windows just locks up immediately. Interestingly, in this lockup state I can hover over icons on the desktop and their backgrounds would highlight, and the hidden Taskbar will even come out if I move the mouse to the edge. However, I can't right-click the Taskbar and get a menu, nor will the system even acknowledge Ctrl-Alt-Delete. I have full access to all folders. It's easily reproducible. However, if I copy the executable from the network location to the local hard drive, the installer will run just fine. Any ideas what could be causing this lockup behavior? A security feature gone wrong? I'm currently experimenting to find out if maybe the system expects to be able to put up a prompt via UAC or something... -Noel

Enabling UAC nets a "Do you want to allow xxxxxxx to make changes to your computer" prompt after a few seconds longer than it seems it should take, but then... Nothing. Same lockup, which never resolves itself. -Noel

FYI, a fresh, clean install of Windows 7 x64 does not do this. I haven't had time yet to try a fresh copy of Windows 7 32 bit. -Noel

Hi Noel, It seemed your account has no permission to run the installer on host system. If your computer is in a domain environment, please login with domain admin account to run the installer from the network. If not, just press Shift + right click the installer and choose Run as different user. After that, type the local admin account on host system. If the issue persists, It also can be caused by the file size. Try a smaller installer file. Also update the network card drivers. If you try a fresh install, please let me know if the issue occurs after that. Best Regards, NikiPlease remember to click "Mark as Answer" on the post that helps you, and to click "Unmark as Answer" if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Thanks for your thoughts. It's not a permissions issue. I use the same username and password across all my test systems (in this case, no domain is involved and the account is in the Administrators group on every machine). The permissions of the files/folders/shares are all Full Control for that account. Using the exact same credentials on a Win7 x64 system, it works fine. It's not a large installer executable - 6.5 MB. Specifically, the latest case where I've seen this is with the RealTech VR OpenGL Extension Viewer from: http://www.realtech-vr.com/glview/download.html Just to be clear, I downloaded this onto my master system, and tried to run it directly from a share on that system on my test system. The keys points seem to be: Everything is being accessed with Administrator privileges. All permissions are right. There's no difference with UAC off or on, nor with Run vs. Run As Administrator, nor with Run As User. I can copy the file from its network location to the local hard drive using Explorer no problem. I can run the installer successfully from the local hard drive. The problem happens on Windows 7 32 bit but not Windows 7 x64. It happens with different installers. At the moment I suspect it's a specific problem in the security software somewhere (certificate handling?) specifically with SP1 for Windows 7 32 bit. My next step is to create a clean 32 bit Windows 7 image and try it without any other software having been installed. -Noel

One other newly discovered piece of information: It may have more to do with the system doing the sharing, not the machine making the connection... A pre-SP1 32 bit Windows 7 system stalls in the same manner. In all these tests a Windows 7 x64 SP1 system is doing the sharing. -Noel

try to enable the option EnableLinkedConnections and try again."A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/

Thanks for the suggestion. It doesn't seem that a mapped network drive has anything to do with this, but hey, I'll look at anything in an attempt to figure the root cause of this one out. EnableLinkedConnections was already set in the client that couldn't execute the software directly from the UNC location. I tried disabling it and it made no difference. -Noel

run the ResourceMonitor in background and look in the network tab if data are still transfered. You can also run a Wireshark trace"A programmer is just a tool which converts caffeine into code" CLIP- Stellvertreter http://www.winvistaside.de/

Everything comes to a grinding halt, as though a resource somewhere in the UI is getting locked/blocked. Even a running Task Manager just stops. I did run Resource Monitor, and watch several things. The text display of running apps stops very soon after trying to run the executable, but the little graphic window keeps going for a while, then it finally stops. All network and disk activity cease. I am starting to think something basic has gone wrong with this particular test VM system, as after reverting it to earlier snapshots I definitely saw work at one time I see they have also stopped. I did get an update to VMware not long ago; that may have been when this problem started. That could mean this is not a Windows problem at all and I've been looking in the wrong place entirely. -Noel

I'm having the EXACT same problem. And I think the problem is even more generic. I'm getting lockups simply trying to copy a file between a 32-bit Win XP or Win 2003 system and Windows 7 using file sharing. It's either very slow or locks up. I think there might be some kind of basic bug in Windows 7 64-bit in relation to the mapped network drives / file shares.

I solved this problem on my environment - I'm wondering if it is the same for you as the symptoms seem Identical I copied the relevant part of the answer from this thread: http://serverfault.com/questions/85965/slow-network-file-copy-on-windows-7 Essentially you have disable the following on your Network Adapter Large Send Offload v2 (IPv4) - Disable Large Send Offload v2 (IPv6) - Disable Hope this helps: Jeff <below copied from other thread> found a good lead on another board (http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/c30f6649-a0d9-4f5e-8671-904a8f5469bb ). Since the problem had a lot of leads which didn't work, I thought I'd cross-post a solution that worked for me. Specifically, my problem was that file transfers FROM Windows 7 to XP were slow, measured by seeing network utilization in the Task Manager at about 1%. Transfers from XP to Windows 7 typically used 80-99% of the network bandwidth. These results were achieved whether the transfer was "push" or "pull". What worked for me: I went to Local Area Network properties, Configure, Advanced Tab, and disabled Large Send Offload v2. The advice to disable autotuning, RSS, set Speed & Duplex to a specific value, remove from homegroup, did nothing. Ultimately, the settings which worked on my Dell XPS 8100 Windows 7 Pro 64-bit workstation were as follows: ARP Offload - Enable Ethernet@WireSpeed -Enable Flow Control - Auto Interrupt Modulation - Enable IPv4 Checksum Offload - Rx & Tx Enabled Large Send Offload (IPv4) - Enable Large Send Offload v2 (IPv4) - Disable Large Send Offload v2 (IPv6) - Disable Network Address - Not present (radio button) NS Offload - Enable Priority & VLAN- Priority & VLAN Enabled Receive Side Scaling - Enable RSS Queues - RSS 4 Queues Speed & Duplex - Auto TCP & UDP Checksum Offload (IPv4) - Rx & Tx Enabled TCP & UDP Checksum Offload (IPv6) - Rx & Tx Enabled VLAN ID - 0 Wake Up Capabilities - Both WOL Speed - Lowest Speed Advertised

Thanks for your input, guys. I have kept a series of snapshots for the virtual machine experiencing the problem, and going back in time I found one that worked. Quite a bit of stuff was done between the time that it worked and the first snapshot where it didn't, including the installation of Visual Studio 2010 beta. In the interest of resuming stalled work, I restored the old snapshot of the VM taken at the time when it worked, and have reinstalled everything I need today, including all the Windows Updates. It still works, so I have a way to move forward. I don't know yet what could have caused the problem - who knows? Something I tweaked maybe. but I'm curious enough to continue investigating... I really hate unexplained things, because they always seem to happen again. I still have the chain of snapshots including the failure, and so I will look at what you have suggested above when I can (the VM is busy with something else this evening). Thanks again. -Noel