We are experiencing a bizarre problem (intermittent and random) when accessing files on our 64 bit 2k3 storage server from networked workstations. For some reasonoccasionally when opening a file off this server or even just scrolling through a folder on the server, the workstation will just lock up. No one else on the network is affected unless they try to access that same folder or file, then they lock up too. The server shows no errors, nothing in the event viewer, no indication of a problem,andI can access that same folder or fileon the server itself with no lockup. This problem only occurs on the 64 bit server, I have two other 32 bit 2k3 servers on my domain and have never had a similar issue with either. The only way to clear the workstation lockup is to reboot the 64 bit storage server. Oncethat isdone that they can access that file or folder normally, they don'thave to reboot or even log offthe workstation.This problem does not seem to be user, workstation, file type, folder, day, or time specific.The only commonality is the 64 bit server. With 30+ users having to back out of there work so I can reboot the server everytime one of them locks up, this is becoming a major issue. Anybody else have a problem like this ? HELP !!!

To whom it may concern, although this is an old post, we too are experiencing a very similar problem with our X64 servers. In our case, it doesn't "lock up" the workstations, but rather locks up explorer when in the current folder accessing files on the X64 server. This is a VERY bizzare issue as mentioned above, and only affect X64 machines. In our case, we can replication this issue by: 1) Copy a file from any machine (32bit or another X64 server) to the X64 server 2) RIGHT after copying, try to click on the file to "preview" it or "open" it from the client machine This locks up the explorer window on the client machine, and interestingly created some sort of bizzare file lock on the server. If you try to delete, open, rename, or do anything with the file, explorer on the server will lock up. Trying to delete the file through command prompt also has no effect. The only way to "unlock" the file is to reboot the server, as the poster above mentions. Interstingly, if you just copya file from the client, and DO NOT try to open it or access it from the client, it remains in a normal state and can be opened on the server side, deleted, renamed, etc. However, any attempt to acces the file after copying it to the server will cause the lockup to occur. Rebooting the server allows the file to be accessible in a more or less normal fashion. We have verified that this is a problem on THREE separate X64 servers, using various clients including Win XP SP3. All exhibit the same issues. These issues are also NOT present when copying to 32 bit servers. The X64 server all patched with the latest patches. Needless to say, this scenario is pretty common when using a server as a file server, and has prevented us from using our X64 for any file serving activities. Interestingly there seems to be VERY little about this issue anywhere, but it seems to be an operating system level problem with X64 machines. Does anyone have any update to this? Is Microsoft even AWARE of this issue? Looks like it's been lingering for a while but I suspect not too many organizations are deploying X64 server on a large scale yet. Look forward to feedback on this or if any else has a similar issue.

Here is another individual that I found with the same problem: We currently run a network of 30+ XP Pro PCs. We have a added a few XP x64 machines and, whilst they can get on the network ok (are visible, can browse and be browsed by others), they give an error when trying to copy files from other computers (both 32-bit and 64-bit). This is the error message:"Cannot copy [filename]: The specified network name is no longer available."However, they work fine if you push the file from another computer (x86 or x64) to the x64 machine.Anybody have any ideas? We move around a lot of data and it is really starting to cause us some issues... Further Info: Right, I've tried the registry changes but they've had no discernible effect.Here's the current situation:- x64 PCs can access files shared on x86 PCs.- x86 PCs cannot access files on x64 PCs - they receive the following error:"Cannot copy [filename]: The specified network name is no longer available."- x64 PCs cannot access files on other x64 PCs - they receive one of the two following errors:"Cannot copy [filename]: The specified network name is no longer available."OR (occasionally and, seemingly, unpredictably)"Cannot copy [filename]: Cannot read from the source file or disk."Also, when I try to copy a file from any PC using x64, I get an Internet Explorer window asking "Do you want to move or copy files from this zone?". Is this a new security step that has been added in x64 or could this have anything to do with it? Someone suggested this registry fix, but it DOES NOT solve the problem: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\ParametersClick Edit, point to New, and then click DWORD Value.Type DisableTaskOffload as the entry name, and then press ENTER.Right-click DisableTaskOffload, and then click Modify.In the Value data box, type a value of 1 , and then click OK.Disable RSS (Receive side scaling)http://support.microsoft.com/kb/912222/en-usHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\ParametersOn the Edit menu, point to New, click DWORD Value, and then type EnableRSS .Double-click EnableRSS, type 0 , and then click OK.

Maybe there is an issue with windows 2008 X64 as well? Again oddly similar... Hello Everyone-My question has to do with Windows Server 2008 64 Bit and network shares. Basically what happens is every few days some of my users start losing the ability to open any network shares to this server or even open their "My Computer" on their own desktop. When the users tries to open "My Computer" the box opens up but there nothing in there and the program has pretty much locked up. If you leave it sit for awhile it might close or timeout where you can do something. Not all users will experience this problem when it happens, just some of them. The only way that I have been able to fix this problem when it happens is to reboot the server. Once the server is rebooted, all the users go back to working normally, until the problem happens again. I have also notice that DFS is inaccessible from this server as well. Not all shares uses DSF in our setup at this time. It's almost like anything that has to do with file sharing on the server has been cut off for some reason.I have checked all the event logs on both side of the network and can't find any reports or events that would lead me to a clue on what the problem could be. There is nothing that I can think of that would lead me to anything to help solve this problem. I hope that someone here has seen this problem or could offer me things to check until a solution can be found for this.System Background:Domain Controllers - Server 2003Exchange Server - Server 2003All other server besides this file server are 2003 or 2003 R2.

While it is good to know I am not crazy, and someone else has experienced this wierdness with Storage Server x64, it is disturbing to find out it or something similar still exists in the 2008 version. I was a little unclear in my first post, when this problem occurs, it is explorer (or any program that uses a file-open menu) on the workstation that hangs up when accessing a file fromStorage Server x64. Theworkstation (XP SP3 x86) does not lock up, only whatever app is trying to access that particular file on the Storage Server and this will happen on any workstation that subsequently tries to access that file until I reboot the Storage Server. So I think my problem is really identical to yours. I have never tried to copy, rename, delete,or move the filewith explorer on the server itself when this was going on, but I will next time it happens. I have also searched for any reference or acknowledgment of this problem from Microsoft to no avail. This is an ongoing issue with me andI would appreciate you posting any info you come across, I will do the same. Thanks.

I have excatly the same problem. I tried to deisbale Netbios over IP and LMHOST too. I am running XP64 Sp2 attached on a Iomega StorCenter. I did'nt found any solution on the web !!!

Well some time has passed, and the issue has not gone away, and like the rest of you I have not been able to find a solution or acknowledgement of an issues from Microsoft. It's very bizzare thatsuch a serious problem would go unreported. It effectively means our X64 server cannot be used as file server at all since browsing any files on them causes the files to be "locked" and the "explorer" to crash on the browsing workstation. VERY unacceptable. Likewise if any of you find a solution let us know. I'm going to upgrade one our machines to Windows 2008 X64 and see if the problem still persists. Will keep you all posted.

I can also confirm that problem exists on Vista X64... for example if I try to browse files on a Vista X64 workstation, it will always fail if I copy a file FROM the X64 box to a 32 bit machine.. then copy it back to the X64 machine.. and try to OPEN the file from the 32 bit machine... it always locks up when trying to open the file... and then if you try to access this same file locally on the X64 machine (open it), it will lock up the file and not allow it to be opened or manipulate in any way until the system is rebooted. I'm just shocked that there is SUCH a huge flaw in X64 editions of windows. Hell, Linux Samba implementations don't have any issues and microsoft can't get it's OWN network browsing technology to work correctly? what a shame :(

I have the same issue. Windows Server 2003 x64, 150 users, app. 30 shares reside on the server. I have contacted MS about this several times and there seems to be no apparent fix for this. I believe I am going to have to transfer all data to x32 bit version, as I know it works on that platform. Alot of the time users cannot create, move, or delete files/folders from the shares. They receive the "file is in use" error, but no one else has the file open. We basically have to reboot the server 3 times a day and it is really annoying. I hope they can resolve this in the x64 bit version sometime before we decide to go to 2008.

Hi Wes... thank you for your input... the more we make people aware of this rather serious problem the better. We are in the process of rolling out Windows 2008 X64 on one of our test servers and once we do I will run some tests on it as well to see if the problem remains.

I have the same issue but with Windows Storage Server 2003 R2 x64, 150 users. 30 shares reside on the server. I have contacted Dell about this being it is OEM. I will resond when I hear back from them.

Same here. Nothing is different on the 2008 machine except the upgrade from 2003 to 2008. I suspect IPv6 is messing around here. MS advises that IPv4 be the default on an SBS 2003 network. I see some strange assignments listed in the IPConfig command line that lead me to the conclusion that this isn't acheived easily. In any case, it isn't mission critical because the server is a SQL Server and it is easy to open the local machine firewall to handle port 1433 over the network. Something else common to the problem is the RPC error which basically states the RPC is unavailable. On Vista and Windows 7, Remote Management Services can be enabled to allow RPC. Is there a service that provides this, yet uses a different name that could be enabled as a workaround on Server 2008?Not sure what the RPC/HTTP Load Balancing is for. I see Vista and Windows 7 users having problems with RPC when they attempt a backup. I have to wonder if RPC isn't related to this inability to reach a disk on a remote machine. Is there a security violoation that is triggered when RPC cannot run and the system determines that Cryptography cannot function properly so it shuts down the access?

Having the same problem server 2k3 x64 locks up exlporer on the user workstations... anyone have a fix?

Hy everyone, it's been a while since I've responded back to this. Basically this problem continues to persist between Windows X64 storage servers and 32-bit XP machines. Since the recent release of Windows 7, I have been updating a few clients to a Windows 2008 R2, Exchange 2010, Windows 7 setup. In one instance we performed an upgrade of the servers to Windows 2008 R2, fresh installs. As expected, the XP workstations began to exhibit the symptoms above, i.e. locking up while trying to browse shared files, with the only solution being the reboot the server to unlock the file in question. We then proceeded to upgrade the workstations to Windows 7, both 32 bit and 64 bit editions, depending on the hardware capabilities. I am happy to report that Windows 7 32bit seems to play nice with Windows X64 file servers. Also Win 7 X64 works fine with X64 server. So basically I can only conclude that Microsoft does not care or does not know about this issue (which I still find shocking) and we will likely never see a fix. Basically, it looks if you want to use 64 bit file servers, make sure you have Win 7 or Vista clients. Otherwise, stick to 32 bit file servers. Hope that helps some of you out there.

PROBLEM SOLVED: Well, after many months, I can finally say the problem has been SOLVED! There were basically two causes of this issue 1) Symantec Anti-virus for X64 and 2) the new samba protocol SMB2 ... basically it seems the earlier versions of Symantec Anti-virus for X64 were causing the file lock-ups to occur... and SMB2 was a factor in slow network performance and opening of files. My solution was two fold, first, disable SMB2 in the registry on Windows 2008 X64 server and reboot:Open Regedit and go to:HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters- Add a new REG_DWORD key with the name of "Smb2" - set value to 0Second, REMOVE Symantec Anti-virus and LiveUpdate... reboot.Third, the latest version of Symantec Enpoint Protection, version 11.05, seems to work just fine... so I re-installed that after disabling SMB2 and network sharing and transfers were once again working perfectly. Both Windows 2003 X64 and Windows 2008 X64 now behave as they should. Lost one too many hours of sleep on this issue, so I helps this helps other with similar problems.