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

Based on the title description, I am pretty sure this is a balls out, ugly bug in Windows 7. I have encountered it on numerous Windows 7 systems when trying to execute an installer from a network location (UNC). I have UAC enabled on all my Win 7 systems and it doesn't matter if they are real or virtual they always lock up when I accidentally try to execute an installer that way. There is some kind of system response initially, but shortly after that the system is completely locked up and doesn't even respond to CTRL-ALT-DEL. The only way to proceed from that point is to hard reset the affected system. I recently got my father-in-law to upgrade to Windows 7 since I was telling him about how it was nicer than XP, but when we were setting up his system it jammed up no less than three times. I felt like an idiot suggesting that Win 7 was better after that. On my network I'm not using any of that HomeGroup fluff; since I also have XP machines on the network. Incidentally no XP machine has any lock up problem; only Windows 7. Anyway I'm not interested in spending days or even weeks tweaking a hundred hidden settings somewhere to try to fix this (else I'd never get any real work done... I've learned that the hard way over the years with things like Windows search, for example) so I'll simply avoid it by copying any installation files locally before executing them. As far as I am concerned, however, this is a pretty easy bug to hit out of the box, with some pretty severe symptoms (hard reset needed) and indicates some problem with Windows 7 that was not present in XP or even in Vista. Wayne H

Interestingly, I've not run into this bug even once more since about April or May 2011. I'm wondering if it might have quietly been fixed via a Windows Update... Wayne, in setting up your new machines on which you're seeing these problems, are the server and "servee" updated to current patch levels? -Noel

Hi Noel, I keep all my systems (real and virtual) up to date using Microsoft Update since I love to be on the bleeding edge! I just ran into the problem again a few moments ago (another hard reset required) which prompted me to check this thread. I may have to start trying to tweak some settings to see what I can do to resolve this. Wayne.Wayne H

>> In all these tests a Windows 7 x64 SP1 system is doing the sharing. << Same for me too, although I think it was the same before SP1 too.Wayne H

I tried the large send off load disable locally (on my file server) and it did not solve my lock up issue when trying to execute an installer via UNC path. Same old symptoms - first the network folder says "Not responding" then the system itself jams up. All for a 2Mb installer file (in this case).Wayne H

Do you see any events logged in either the server or client Windows Event Logs coincident with the failure? Unfortunately I've never had it happen again since early 2011, as I reported before, and investigating it further has simply fallen off my list of things to do. Notably I'm running the same installation on the Windows 7 x64 system as always. If anything, only the VMs and other systems here have changed (and of course, all systems have continued to receive Microsoft updates). -Noel Detailed how-to in my new eBook: Configure The Windows 7 "To Work" Options

Hi Noel, Sorry I never got back to this thread; many things going on. Since the time above I have built myself a new desktop that also doubles as a file server and the previous system is now my wife's desktop. I noticed when setting this new system up that when an XP machine connects to it, it may have problems connecting and when it does I can end up with tons of events in Event Viewer on the server. I'm going by memory here, but I think the IDs were 2017 and 2019 (potentially also 2021). Anyway, trying to get to the point, I did some research and made a few registry tweaks to my new system so it will behave more reliably in its dual file server role and avoid all those events in Event Viewer. I can't recall off the top of my head what these tweaks were, but I think one was turning on LargeSystemCache. (No problems with memory here since I now have 32GB). (I just did a quick search and although this is not the link I used, this is the gist of the changes I made:) http://www.computer-how-to-guide.com/windows-software/event-id-2017-2021/ So with those settings in place things have been fine for XP access (for a couple of weeks now no more events in Event Viewer) and it got me wondering that whether this lock up on running an installer via UNC isn't also somehow related to resources allocated to file server tasks on the file server (i.e., the host of the installer). Thinking out loud, running an installer over the network is going to probably end up in a lot more connections than usual since multiple files will be created and accessed from the server when doing an install. So I just tried testing the installer over the network from a Win 7 client; I installed VMware workstation 8 which is a fairly big installer (> 400MB). It seemed to work pretty well (no lock up). I also tried X1 and it worked too. Now the question is that did this problem go away when I changed server or is it potentially related to the configuration on the new system for the file server use case? I guess I probably won't ever know the answer to this now, but since my problem is also solved I will no longer worry! Cheers. Wayne H