Shared drive on XPx64-SP1 not accessible thru LAN

[FONT=&quot]I am getting error messages when attempting to open a shared drive on XPx64-sp1 machine from Vistax64-sp2rc machine:[/FONT]
[FONT=&quot]---------------------------[/FONT]
[FONT=&quot]Open Folder[/FONT]
[FONT=&quot]---------------------------[/FONT]
[FONT=&quot]\\ULTRA-WX64\DTs01i (D) is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.[/FONT]
[FONT=&quot]Not enough server storage is available to process this command.[/FONT]
[FONT=&quot]---------------------------[/FONT]
[FONT=&quot]OK [/FONT]
[FONT=&quot]---------------------------[/FONT]
[FONT=&quot]There are 5 machines in the LAN which are WX64-sp1, WX86-sp3, WV86-sp1, WV64-sp2rc, and W7x64. There is no problem among the latter 4 machines but a shared drive on WX64 can not be accessed from any of the latter 4 machines. There is no problem with RDC to the WX64 from any other machine.

I attempted to install on the WX64, Link Layer Topology Discovery(LLTD) Responder, KB922120, but an error message said that this is for different hardware platform, and could not install it.
I noticed that the system event log showed system event ID of 2011. MS KB article says that resolution for this problem is modifying IRPStackSize value, so I did, but no go.
The problem may be due to my dumb mistake or oversight somewhere. Any suggestion would be appreciated.[/FONT]

Make sure you're modifying the IRPStackSize on the target (XPx64) under HKLM\System\CCS\Services\LanmanServer. That error almost always means an IRP-sizing issue, so I think you're on the right track.

What are you setting the IRPStackSize to? Try 50 (decimal) as a test, then if that works bring it back down to just over the point where it starts failing again... 40, 35, 30, 28...

Thanks for your response.
IRPStackSize was not there, so I created it per MS KB article. The article says the default value is 15 so I set it so. Then, increased it to 18 as suggested in the same article. Still it did not work and I stopped there.
This time I tried 50 as suggested by you, but to no avail. The article says 50 is the maximum for W2K, which I assume may also be the case with WX64(Windows XP x64).
I carefully double checked the location where the IRPStackSize was inserted.

Do all 4 other machines see the same error ("not enough server storage...") when they try to access shares on the XP64 box?

Can the XP64 machine access its own shares? (start, run, \\OwnName\OwnShare)

Does it work if you boot the XP64 machine to [safe mode + net]?

H2SO4 said:

Do all 4 other machines see the same error ("not enough server storage...") when they try to access shares on the XP64 box?

Click to expand...

Yes, except W7 box. I used to see WX64 on W7 but now it is not shown on W7. Let me scratch W7 box since W7 is beta version.

Can the XP64 machine access its own shares? (start, run, \\OwnName\OwnShare)

Click to expand...

No, the exact same error message is returned !!.

Does it work if you boot the XP64 machine to [safe mode + net]?

Click to expand...

Yes, it works.


The above are new knowledge to me. I wonder what those are pointing to.

Edit:I did the following subsequent to the above:
On the MSConfig, I changed "Normal Startup" to "Selective Startup" with "System Services" only check marked. It worked. Then the Startup items were partially turned on. It still workd. Then all items were turned on, but the problem never came back.
I am not sure if I checked to see the problem still exited in normal mode after the experiment was done in safe mode. Only explanation I can think of is that booting the WX64 box in safe mode just fixed the problem. Any comment is appreciated.

Glad to hear things are looking up.

The problem is obviously on the XP64 box and there's no obvious reason why booting to safe mode would by itself fix anything. My first thought is whether you perhaps hadn't rebooted (or restarted the Server service) previously after adding IRPStackSize? In that case a reboot to safe mode would have appeared to make the difference, but in fact all it did was to cause the new IRP size settings to take hold.

In any case, if it's working now you'd want to experiment with reducing IRPStackSize back down and testing. Otherwise, if it's unnecessarily big, it can consume undue amounts of a precious resource called "non-paged pool" which is still limited even on a 64-bit box because of the finite amount of RAM.

The "not enough server storage..." message can be thought of as "there are too many drivers in the I/O stack and they can't all get to do what they want because the structure where they record what is to be done (the I/O Request Packet - "IRP") is currently too small". It can sometimes also be a single errant driver that's simply buggy. AV and backup agent drivers are a common cause.

You guessed it right: I did not restart the WX64 box when adding IRPStackSize or adjusting its value. I thought changing registry is effective immediately without rebooting the system. I have just reviewed the MS KB article and found that "Restart the computer" is the last step to do.

As suggested I adjusted the value. I started with 15 and the problem went away with 20, so I stopped there. I wonder if I should allow more margin with 25 perhaps?

Does your explanation about "Not enough server storage ... " means I may have to increase the value again in the future?

IRPs are not a simple thing to analogise. Think of an IRP as a "work order" document where every driver that's interested gets to write a series of instructions for what should happen when the user attempts to open a file or similar. The more drivers, the more activity, and the bigger the IRPs need to be to describe all of it. When more drivers are installed, especially those with "inspection" roles such as anti-virus, anti-malware, firewalls, and so on, space in the default-sized IRP can run low to the point where the user-requested activity is cancelled. That's the "not enough server storage..." message.

Cranking up the default size of an IRP obviously helps, and in your case you've established that somewhere between 15 and 20 is the right number for your machine and your specific combination of drivers. The reason you don't want to just crank it up to the maximum (50) and leave it there is because there can be maaaany IRPs active at any one time, and each one consumes pool memory corresponding to its size, irrespective of whether it's only 4 out of the 50 slots that are used, or all 50. (An obvious question is why don't IRPs just grow as necessary, but it doesn't work that way.)

If your system is running without errors at 20, I'd suggest you leave it there. Odds are that even 16 or 17 would have been enough, but 20 gives you a bit of overhead. Should you add a whole heap of extra drivers in the future, it's possible that you'll again start seeing the same "not enough server storage..." error, and then you just bump it up to 23 and test again. No big deal.

What confuses most folk is the wording of the error. "But, but, I've got 4GB of RAM and 500GB of space - how can I be running low on storage?!?" The difference in your case is that you looked up the error message. Have some rep

Thank you very much for further details of IRPs and all the help to solve my problem. Important lesson I learned through this is that not all registry changes become immediately effective without rebooting the system.
I thank you again, H2So4.

No problem at all churin

Not all registry values are the same in this regard. The registry is just a repository where many different components all store their settings. Whether a particular registry change will take hold immediately depends on the component which reads that value, or rather how often the value is read. The settings under \services\LanmanServer, including IRPStackSize, are read whenever the "Server" service starts. Normally, that's only at boot time, unless you manually restart the service (NET STOP SERVER / NET START SERVER, or use the services.msc applet).

Other components may re-read their registry changes on a timed schedule, or a full reboot may be required. There's no absolute rule.

Thanks for your further clarification.