none
Major bug in Vista File Sharing (Peer-to-Peer)?

    Question

  • Major bug in Vista File Sharing (Peer-to-Peer)?

    Description:
    Microsoft Vista will lockup when more than one Vista workstation attempts to access the same file in a shared folder at the same time.

    Steps to reproduce:

    1. Install a new copy of Vista (Does not matter what version) on two different computers.
    2. Install a new copy of MS Office 2003 each computer.
    3. Share the Public folder on one of the machines so that other computers can access it. (We will call this Machine A).

    4. On Machine A, create a new MS Word document in the Public folder and leave it open.

    5. On Machine B, browse to the network share on Machine A and try to open the same Word document.

    MS Word will freeze and will not come back until the file is closed on Machine A.

    More Information:

    This same thing will also happen with MS Access files (MDB).

    Now oddly enough, if Machine B is running Windows XP everything runs just fine.

     

    Does  anyone know a workaround for this issue?

     

    Thursday, February 22, 2007 8:10 PM

Answers

  • This appears to be a problem with the new SMB2 protocol developed for Windows Vista.  For a brief description of what SMB2 is, See: http://wiki.ethereal.com/SMB2

    Disabling SMB2 on the machine that hosts the share seems to solve the problem.  Share works fine when a Windows XP machine hosts the shared folder because XP does not support SMB2 and the machines connecting will use SMB.

    So far this is an undocumented problem only known by Microsoft's internal support staff, so use this information at your own risk.  It is unkown if disabling SMB2 will have any other side-effects.  To disable SMB2 on the machine hosting the shared folder, add a registery value named SMB2 under HKEY_LOCAL_MACHINE/SYSTEM/CONTROLSET/SERVICES/LANMANSERVER/PARAMETERS and set it to 0.  Reboot.

    We are recommending that our clients set up an XP machine to host the share until the problem is addressed in a real MS Knowledgebase article with proven results or until a fix is provided.

    Wednesday, March 7, 2007 2:40 PM

All replies

  • Having the same issue.
    It is severly hampering us - any resolution yet?

    Kurt

    Friday, March 2, 2007 7:18 PM
  • Sorry... none at this time.

    I have even tested this now in Access 2007 with the same results.

    We are losing a lot of money over this because our customers systems are failing with Vista installed.

    If anyone from Microsoft is seeing this post..PLEASE HELP!.

     

     

    Friday, March 2, 2007 8:41 PM
  • Agreed - something tells me we're missing something. Could the beta testers really have missed something this big???
    Saturday, March 3, 2007 2:38 AM
  • I thought that too at first, but just look at the facts.

    It cannot be security or sharing properties cause everything works until you try to access the file simultaneously and other XP machines hanging on the exact same network function properly.

    The last nail in the Vista coffin is that it does not report an error it simply locks up and not even Task Manager can terminate the process until you close the file on the Machine that has it opened.

    If I had to guess I would say that the bug must be in the Vista code that is attempting to limit the number of simultaneous users on the network share. In my testing this only seems to affect other Vista workstations anyway. XP machines on the same network are not limited by this setting.

    Example: If you set the Limit to just 1. No other Vista machine can access the share but XP machines on the same network can. Perhaps this is just another bug, but my guess is that it is related to this problem somehow.
    Saturday, March 3, 2007 8:19 PM
  • Good points.
    As an aside, in my issue, the software (Design Manager www.DesignManager.com) locks up for about a minute after which it claims the database it's trying to open is corrupt (which it's not). Close the application on the other Vista PC and it opens fine.

    Same problem, slight variation.

    If I can take it a step further.

    Database is hosted locally on PC 1. PC 1 opens it fine. If PC1 opens the DB, PC2 (on the network) cannot open it. HOWEVER, if PC2 opens it 1st then both PC1 and PC2 (but no others) can be in at the same time. Thus, opening from PC2 is the only way I can get the DB to open on more than 1 PC. And, in no situation can I get more than 2 PCs into at once.

    Just adding a few more tid bits . . .

    Monday, March 5, 2007 12:06 AM
  • Right now we have two programs down due to the same share bug, and I have searched and searched but can find no answer.

    I have posted on many MSDN forums and the OEM center and no MS rep repsonds what is with that????

    They are letting us hang ourselves.  I guess back to XP Pro

    Monday, March 5, 2007 1:47 AM
  • Just to add...Design Manager uses a Jet 4.0 database (like Access 2007).  As soon as the machine that is hosting the share opens the database, all other Vista computers are locked out and either hang or eventually return a "not Reponding" message (which our program interprets as a possible corrupted database and drops into a repair mode).  We will be contacting Microsoft support on the issue and I will let you all know the outcome.
    Monday, March 5, 2007 3:05 PM
  • What happens when you just share a text file and open it by MS Word   or  Notepad?

    Wednesday, March 7, 2007 9:18 AM
  • This appears to be a problem with the new SMB2 protocol developed for Windows Vista.  For a brief description of what SMB2 is, See: http://wiki.ethereal.com/SMB2

    Disabling SMB2 on the machine that hosts the share seems to solve the problem.  Share works fine when a Windows XP machine hosts the shared folder because XP does not support SMB2 and the machines connecting will use SMB.

    So far this is an undocumented problem only known by Microsoft's internal support staff, so use this information at your own risk.  It is unkown if disabling SMB2 will have any other side-effects.  To disable SMB2 on the machine hosting the shared folder, add a registery value named SMB2 under HKEY_LOCAL_MACHINE/SYSTEM/CONTROLSET/SERVICES/LANMANSERVER/PARAMETERS and set it to 0.  Reboot.

    We are recommending that our clients set up an XP machine to host the share until the problem is addressed in a real MS Knowledgebase article with proven results or until a fix is provided.

    Wednesday, March 7, 2007 2:40 PM
  • Thank you Joe.  We have verified that this indeed does correct the problem. However, like you we will not recommend this fix to our clients until Microsoft posts this as the correct solution or otherwise posts a solution to this problem as we have no way to know what other problems this fix will introduce.  I made a few slight changes to your workaround (see below).

     

    Again, thank you very much for properly identifying this bug. Let's hope MS posts a patch to this soon.

     

    Workaround

     

    On the Vista workstation acting as the server.

     

    1. Run REGEDIT.

    2.  Navigate to the key.

     

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters.

     

    3. Click Edit>New>DWORD (32-bit) Value.

    4. Enter SMB2 as the new value name.

    5. Exit REGEDIT.

    6. Restart Windows Vista.
    Wednesday, March 7, 2007 6:29 PM
  • This is truly amazing.
    I can't wait for Microsoft's explanation of this one.

    Friday, March 9, 2007 11:45 PM
  • We are experiencing the same problem.  It appears to afflict all versions of access.

    Microsoft really needs to "resolve" the issue.  It is turning out to be a  major problems for developers and companies that do not use sql servers.  You have to wonder if microsoft "overlooked" this or did they?

    Do they want to force everyone to sql server?

    With the number of issues in vista, they should not be distributing it on new systems.

    That or they should have a "FIX" available and widely distributed.  Right now you either have to hack the registry to fix it, or tell your customer go and find and XP box.

    And of course the HACK is undocumented and does not really say what other effects it will have on the operating system.

    It is wrong on so many levels.

    Especially when the customer have no idea of what really is going on.  The customer just thinks that it is a problem with "Your Software" because windows vista comes on and office works.

    PLEASE  Microsoft get this resolved. ASAP.

    Best Regards

    Wednesday, March 14, 2007 12:46 AM
  • Not only does this issue need to be resolved, but we need a KB article explaining the issue. It is just plain embarrassing when you have to tell your clients that "this is a known issue in Vista" and have no official statement from Microsoft. It makes it look like the problem is on the application side for the client and as if the app-vendor was just passing the blame to someone else instead of owning up...

    Isn't it great - one of the workarounds could be to use a linux-based server (or any of the similar NAS devices). :-)
    Wednesday, March 14, 2007 10:13 AM
  • JohnMu is 100% right!
    same Problem here with our application (working with ms access db).
    if only m$ would give us a official statement

    cowards - cannot stand to their own bugs.
    sad very sad ....
    Wednesday, March 14, 2007 7:03 PM
  • First, I have to say thank you to all of you who wrote in this thread, I am so happy I finally found a workaround for this showstopper bug for sharing Access databases in Vista. I spent so many hours trying different options, troubleshooting and searching the web, before I found this thread.

    But I'm wondering, does anyone know if Microsoft really is aware of this bug? I have searched Microsoft.com for a place to submit a bug report, but so far, I have not been successful.

    I deeply regret installing Vista in my small business at this point, I have had so many issues and have lost so many days of productive work it is ridiculous. This operating system simply is not ready for business use - on my home machine it is nice, but as soon as you add networking, VPN, or legacy dos apps to the mix, it becomes a disaster.

    Thursday, March 15, 2007 9:56 PM
  • Jonne,

    I feel your pain.

    IMHO They are really trying to discourage people from contacting support and have built a wall around their company to reduce overall support costs. They now rely too much on the developer and user communities to solve their problems for them.

    If you call MS Support, they will first want to take a credit card and charge you for a support call. If they determine that it is a real bug they say they will refund your money. The assumption that they make is that it is always the customers’ fault and never a bug in their product.

    Don’t bother with on-line support chat. It is an exercise in futility. I tried this and the guy said he was searching for a solution to my problem before I even told him what the problem was.

     
    As strange as it may seem they recommend that you submit the bug report via snail mail. We have done this and I would suggest that all reading this do so as well. If enough people do this and also go though the support route we may eventually get their attention.

    FYI - Ran a Windows Update on 3/15/2007 and still no fix.

    Report bug to...


    Windows Vista Development Group
    Microsoft Corporation
    1 Microsoft Way
    Redmond, Washington 98052

     

     

    Thursday, March 15, 2007 10:33 PM
  • jchurch, thanks for the info. I might just try and write a snail-mail.

    At this point, I am totally fed up with Vista, and my absolute recommendation to anyone running a small business is: do not upgrade to Vista, at least until Service Pack 1. It is chock-full of bugs and issues.

    Wednesday, March 21, 2007 11:22 PM
  • Oh, right, so my feeling was true!
    I've written a post in the past days about a strange behavior of the Windows LockFile API when used to lock a file through the network, on a Vista-2-Vista file sharing situation.
    I thought it could be a bug, since in some conditions it would not return a response but would lock and wait until it could acquire the lock.
    This thread confirmed my doubts about it.
    Thursday, March 22, 2007 9:20 AM
  • Unfortunately adding the registry value didn’t work for me because after the reboot the rest of the Vista machines were unable to view it’s shared files.  We are now hosting the .mdb on an XP machine but strangely the only way to actually open the file remotely is to open access on each machine and then open the shared networked file.  Attempting to open the file without access open gives you the green circle for a second then it goes away.  I hope they get this fixed soon.

    Friday, March 23, 2007 3:40 PM
  • This may or may not be the same bug, but here's a useful KB article:

    http://support.microsoft.com/kb/931770/en-us
    Friday, March 30, 2007 1:13 PM
  • Thanks for reporting this problem. The team is actively investigating this and I will update this thread when we determine the cause.
    Monday, April 2, 2007 7:06 PM
  • My company makes software and some people choose a shared folder, peer-to-peer configuration.  We've had no complaints with Windows 2000 or XP users, but a recent Vista user is having the exact problem everyone else in this forum.  I tested the same setup on our systems and got the same problem as our customer.  I then tried the SMB2 registry hack and it worked.  We won't be recommending the registry hack as a solution to customers until Microsoft has made an official fix.
    Monday, April 23, 2007 5:29 PM
  • I have written a small C++ program that demonstrates the problem with the LockFile function when used on a file that is shared between two computers running Windows Vista. Instructions for running the test are in the comments. I have called MS support and opened a case with them and was promised a call back, but have not received one yet. The case number is SRX070426602072.

    Jeff Bean
    CWC Software

    // LockRangeTest.cpp
    //
    // Demonstrates locking problem with Windows Vista

    // This program demonstrates a bug in the file sharing facilities of Vista
    // You will need two computers running Windows Vista (I used Vista Business),
    // call them computer A and B. Create a shared folder on A, named C:\Shared.
    // Share the folder on the network.
    //
    // On Vista computer A, run this program using the command
    // LockRangeTest \\A\Shared\Test.tmp
    // It will create the file named Test.tmp and output the messages
    // "About to lock the first four bytes of the file."
    // "This should either succeed or fail immediately, not hang."
    // "First four bytes of file is locked. Press any key to quit."
    // Do not enter anthing yet.
    //
    // On Vista computer B, run this program using the same command
    // LockRangeTest \\A\Shared\Test.tmp
    // You will get the first two message lines, but not the third one.
    // "About to lock the first four bytes of the file."
    // "This should either succeed or fail immediately, not hang."
    //
    // The program on B has hung in the LockFile call. This should never happen.
    // The LockFile call should either succeed or fail immediately, not hang.
    // If you repeat this test using two Windows XP computers, the second instance
    // of the LockRangeTest program correctly reports a failure of the LockFile call.
    //
    // Interestingly, this does not occur if you reverse things:
    // On Vista computer B run this command:
    // LockRangeTest \\A\Shared\Test.tmp
    // On Vista computer A run the same command:
    // LockRangeTest \\A\Shared\Test.tmp
    // The second instance, now running on A, accessing a file on A does not hang.
    //
    // The LockFile function only hangs when the first instance locks a file on its own drive
    // and the second instance is run from a computer other than the one where the file resides.

    #include "stdafx.h"
    #include "windows.h"
    #include <iostream>
    #include <conio.h>
    using namespace std;


    int _tmain(int argc, _TCHAR* argv[])
    {
        HANDLE hFile;
        _TCHAR *pszMsgBuf;
        DWORD   dwData;
        DWORD   dwBytesWritten;
        DWORD   dwLastError;

        if (argc < 2)
            goto SHOW_USAGE;

        // Open or create the file named in the first command line argument

        hFile = CreateFile(argv[1],
                           GENERIC_READ|GENERIC_WRITE,          // Request read/write access
                           FILE_SHARE_READ|FILE_SHARE_WRITE,    // Allow shared readers and writers
                           NULL,
                           OPEN_ALWAYS,                         // Create file if it doesn't exist
                           FILE_ATTRIBUTE_NORMAL,
                           NULL);

        if (hFile == INVALID_HANDLE_VALUE)
            goto OPEN_FILE_FAILURE;

        if (GetLastError() != ERROR_ALREADY_EXISTS)
        {
            // File did not exist. Write some data to it.
            if (!WriteFile(hFile,&dwData,sizeof(dwData),&dwBytesWritten,NULL))
                goto WRITE_FILE_FAILURE;
        }

        // Lock a range of bytes
        wcout << L"About to lock the first four bytes of the file." << endl;
        wcout << L"This should either succeed or fail immediately, not hang." << endl;
        if (!LockFile(hFile,0,0,sizeof(dwData),0))
            goto LOCK_FILE_FAILURE;

        // Wait for user to enter anything
        wcout << L"First four bytes of file is locked. Press any key to quit." << endl;
        _getch();

        return 0;

    SHOW_USAGE:
        wcout << L"Usage: LockRangeTest filename" << endl;
        return 1;
    OPEN_FILE_FAILURE:
        dwLastError = GetLastError();
        wcout << L"CreateFile call failed" << endl;
        goto REPORT_ERROR;
    WRITE_FILE_FAILURE:
        dwLastError = GetLastError();
        wcout << L"WriteFile call failed" << endl;
        goto REPORT_ERROR;
    LOCK_FILE_FAILURE:
        dwLastError = GetLastError();
        wcout << L"LockFile call failed" << endl;
        wcout << L"This is expected for the second instance of the program" << endl;
        goto REPORT_ERROR;
    REPORT_ERROR:
        FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM,
                      NULL, dwLastError, 0, (LPTSTR)&pszMsgBuf, 0, 0);
        wcout << pszMsgBuf << endl;
        LocalFree(pszMsgBuf);
        return 1;
    }

    Saturday, April 28, 2007 5:19 AM
  • Does anyone yet know exactly what all disabling SMB2 effects? It would appear Vista simply falls back on the previous version.
    Monday, April 30, 2007 2:32 PM
  • Hi,

    there is a Microsoft Patch for this Problem - you have to call (free of charge) to get the patch.

     

    look at this KB-Article ... http://support.microsoft.com/kb/935366/en-us

     

    Cheers,

    Herbert  

    Wednesday, May 2, 2007 2:15 PM
  • This is not right, IF this is the fix,  http://support.microsoft.com/kb/935366/en-us

    microsoft should make this available to ALL users without calling.

     

    Its hard enough to explain to customers that it is an issue with "MICROSOFT" let alone getting them to call and request it.

     

    It should be available to "ALL" end users and especially "DEVELOPERS".

     

    Its has been months that the problem has existed, and YET Microsoft still has not officially made a statement or public resolution on it.

     

    Guess it is YET ANOTHER reason NOT to move to Vista.

     

     

    Tuesday, May 8, 2007 2:48 AM
  • Yes, KB 935366 is the fix. Microsoft sent me the hotfix after I called and that patch did fix the problem. Unfortunately they won't let us redistribute the hotfix to our customers. Here is what they said:
    I had a discussion with my two of my senior colleagues.  The short summary is that your customers will need to call Microsoft support and ask for the hotfix to KB 935366.  The fix will be included in Vista SP1.

    There is a high bar for companies who want to redistribute fixes with their product. The biggest two are
    1. The ISV must plan on shipping the redistributable package with their setup. The fix is distributed as a custom action during setup rather than just a standard hotfix.
    2. The ISV must keep track of ALL customers who receive the fix.

    Redistributable hotfixes are mostly issued to premier accounts where there is a Technical Account manager (TAM) at Microsoft representing the customer. The TAM is the person that does the leg work in following all of the processes to get things done. Even then, it doesn't guarantee that the request will be approved.

    I agree that they ought to make the patch publicly downloadable. It really is a pretty serious problem. The only mitigating circumstance is that we can tell our customers to disable the SMB2 protocol via the registry change referenced earlier in this thread. Of course, months from now when they install Vista SP1, they won't remember to undo the registry change and who knows what problems that might cause.
    Tuesday, May 8, 2007 4:11 AM
  • I just want to add my 2 cents.

     

    We have an application distributed to 200 businesses nationwide which utilizes Access 2003 on the backend.

     

    We can verify, without a doubt, that  2 simultaneous vista machines cannot connect at the same time to a shared mdb file on another vista system.

     

    It took us 2 weeks to locate this article and a very (understandably) upset customer who thought the problem was our software and not VISTA.

     

    There should be a public hotfix in the KB so that everyone can download and install the hotfix for this issue ASAP.

     

    Wednesday, June 27, 2007 9:27 PM
  • Vista also falls apart when I copy one directory from c: drive to e: drive in Windows Explorer

     

    The directory had thousnads of files in it and about half way through the copy my screen goes random multi coloured and the PC locks up. It happens every time.

     

    Vista also wont allow aero if you install Apple Quicktime.

     

     

     

     

    Monday, July 23, 2007 12:36 PM
  • Vista can also lock up when using Windows Explorer to copy large amounts of files.

    Disk defragmenter also does the same.

     

    On my machine video memory is taken from system memeory and when the above crashes the PC it writes up through memory and through the video buffer displaying lines across the screen.

     

    There is an issue with Vista C# and openfiledialog, on closing keyboard focus is lost from the main form.

    After every openfiledialog I have to add this.Focus(); to get keyboard focus back.

     

    Mouseover on a menuitem gives a grey background, on XP it does not.

    This resulted in my menus havin gwhite text on a grey background which is unreadable.

     

     

     

     

     

    Thursday, August 2, 2007 11:20 PM
  • I have experienced the same issue.  Microsoft has posted a Knowledge Base Article about this at http://support.microsoft.com/kb/935366

    Friday, November 30, 2007 12:50 PM
  • I think the key should be /CURRENTCONTROLSET/  instead of CONTROLSET.

    I seem to have had to change it in CURRENTCONTROLSET and in CONTROLSET002

     

    Then it worked.

     

    THANKS!!!!

    Friday, November 30, 2007 10:37 PM
  • It is possible that Remote Differential Compression is the issue here.  Have you tried uninstalling it with ocsetup.exe?

     

    Check the technet explanation here.

     

    http://technet2.microsoft.com/WindowsVista/en/library/e46aa15c-372e-4e9b-9324-ba5fb73059ca1033.mspx

     

    RDC can be removed by issuing a "ocsetup.exe MSRDC-Infrastructure /uninstall /quiet" at the command prompt.

    Friday, January 4, 2008 1:30 AM
  • A friend of mine called me yesterday and told me that there appears to be a major bug in Vista File Sharing on Peer to Peer setups...
    Monday, April 28, 2008 8:01 PM
  • For reference this also works with 2008 Server STD

     

    Wednesday, May 28, 2008 12:42 PM
  • JCHURCH:

     

    This absolutley works.  I have 3 workstations P2P all running vista.  When you file share with more than one computer, they all bog down and lock up.  Thanks for the fix!  This was not corrected with SP1 even though MS thinks it was.

     

    Tuesday, June 10, 2008 11:47 AM
  • I have the same problem as listed i.e., with the Access database file not able to share from Windows 2008 server std. Works perfectly well with the windows 2003 server we have in the same domain, but not from 2008. I tried all the above listed remidies, but these stops sharing altogeather.  Please help!!!!

    Thursday, November 13, 2008 9:21 PM
  • We are on Vista Business SP1 with all the latest patches and have the issue with MAS 90.  We cannot open it on both computers at the same time.  Sage even says it is not supported because of an issue with file locking on SP1. 

     

    We just bought the computers and it came with SP1 installed.  If anyone has found a knowledge base article besides the "Access may stop responding when you open a remote database" which they claim is fixed in SP1 please post it.

     

    Thank you

    Monday, November 17, 2008 4:48 PM
  • if you don't have access to the server's registry you can disable SMB2 on the client side instead. 

    from an elevated command prompt, run the following:

    sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
    sc config mrxsmb20 start= disabled

    more info:

    http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

    http://blogs.technet.com/askperf/archive/2008/05/30/two-minute-drill-overview-of-smb-2-0.aspx

    WARNING: Vista SP1 does NOT fix all SMB2 issues - I highly recommend it be disabled on the client side so that no matter what server you access, you will not get SMB2.  This will protect you from future OS updates, and force your client to continue to negotiate an SMB1 connection with whatever server you connect to.
    Monday, March 9, 2009 3:55 AM
  • I bumped into the same issue and saw this forum which pointed to the update fix http://support.microsoft.com/default.aspx/kb/935366

    This fix made a point to get yourself to the latest service pack (SP2) before requesting. The Windows Vista PC's and the Windows Server 2008 were not at SP2. Once I put that service pack on every PC and server this fixed the problem.

    FYI as looks like this post hasn't been updated post SP2


    Thursday, October 29, 2009 6:46 AM