Data Centers

Troubleshooting BSOD when saving files to the network in Windows XP

Derek Schauland had to troubleshoot some BSOD errors resulting from a user who couldn't save Microsoft Office files to the network. Here's the registry edit he found to solve the problem.

Recently in my organization, I came across a workstation that would flip a blue screen when trying to save an office document to the network. The usual investigation began for viruses and spyware on the computer, which yielded a few cookies and some pop-ups,but nothing that a thorough scan could not handle.

After sweeping and scanning for anything I could find, I thought this was going to do the trick, but further attempts to save from an office application to a share on the network continued to cause the same blue screen. The message displayed when the stop error occurred was as follows:

No_More_IRP_Stack_Size_Locations

I scoured the Internet and found a good deal of information regarding issues with conflicting antivirus applications, which made think that scanning the system with additional applications could be causing the issue, but after removing the additional scanners continued attempts produced the same error.

Creating files on the network share from Windows Explorer worked without any problems, as did copying or moving files there.

IRP_StackSize modifications

Some further research on the Internet brought me to two solutions, one involving the IRP_StackSize on the local machine and on the server living in the registry at

HKEY_LOCAL_MACHINE\CurrentControlSet\Services\LanManServer\Parameters\IRPStackSize

I found at first that the key did not exist and created a DWORD value with a value of Decimal 15 to start off with. After a restart, the error continued when saving to the DFS share. I changed the value on the workstation several times in increments of 5 and got nowhere fast. Then I discovered that networks using DFS shares had a different stack size setting found here:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Mup\Parameters

The DFSIrpStackSize entry did not exist here either. Once I added the DWORD value for the DFSIrpStackSize and set a maximum value of 10, I restarted the machine and found that I was suddenly able to get office documents saved directly to the DFS share with no error. This Registry entry has a default value of 5, once created. The other acceptable value is 10, but setting it to anything other than 10 restores the default value of 5.

Here are the exact steps that I followed to add this value to the registry and solve the problem:

Note: Modifying the registry is not recommended. In the event you need to modify the registry, be sure to create a backup of the existing registry before changing any data. Editing the registry requires an administrator account

1.       Open the Run box by clicking Start | Run.

2.       Type regedit in the run box and click OK.

3.       Navigate to HKEY_LOCAL_MACHINE and then expand System.

4.       Then navigate to CurrentControlSet | Services | MUP | Parameters.

5.       If theDFS IrpStackSize item does not exist, right click and choose New | DWORD.

6.       Enter the name for the object exactly as shown:

DFSIrpStackSize

7.       Press Enter to store the object within the registry.

8.       Right click the new entry (or the DFSIrpStackSize object if it already exists) and select Modify to change the value of the object.

9.       Change the base type to Decimal and enter a value of 16 as shown in Figure A.

10.   Click OK when you have changed these values and close the registry editor.

11.   Restart the computer for the registry changes to take effect.

Figure A

Modifying the value of DFSIrpStackSize

Because the computer experiencing the issue was already running Windows XP Service Pack 3, the required hotfix was already installed on the system. For computers running Windows XP Service Pack 2, a hotfix is required along with the mentioned registry modifications to correct the issue. More information and instructions on obtaining the hotfix from Microsoft can be found here: http://support.microsoft.com/kb/906866.

Based on information I have seen about possible conflicts between antivirus applications causing similar issues, I will continue to monitor the situation to see if anything else pops up. For me, the discovery of IRP-related keys in the registry provided a fix that did not involve formatting and rebuilding the PC, which was a huge relief.  Hopefully this post helps you correct this issue and avoid this problem in your organization.

About

Derek Schauland has been tinkering with Windows systems since 1997. He has supported Windows NT 4, worked phone support for an ISP, and is currently the IT Manager for a manufacturing company in Wisconsin.

Editor's Picks