OK, I've had this happen before, such as when I installed AVG AV. I know the trick for the IRPStackSize reg edit.

However, I am encountering more and more of this on my network on CPU's and drives that never did this before. Strangely enough, it may affect only some of the drives on a CPU and not others. I've tried all different settings for the StackSize value and it does no good. None of these CPU's has had AV on them as they don't sit on the web and are on a closed network. I had one CPU that was fine this morning and on the next reboot I could not share a video folder any more, but every other share off it worked fine. Anyone else encountering this?

Thanks.

i'd have to go dig up the details again but could you indicate:

- What operating system/service packs are installed on the machines
- What is is the CURRENT irpstacksize value you have (knowing, of course, you have to reboot for it take affect)

Initially, for a fix, i'd try resetting all sharing and reboot. The turn sharing back on.

and how many shares do you on defined on each machine?

LoookinAround:

I am using XP Pro SP3 and sharing 4 volumes, 2 are drives attached to the mainboard directly, 1 is an ATA pass-through on a 9500S-8 controller, and the other is a 4-drive RAID 5 volume on the 9500S-8 controller. The 9500-mounted drives work fine. The drives directly attached to the system board cause the error Current IRP stack size is 50 (max for XP Pro if I am reading other articles correctly). I have tried the resetting sharing, including one article I found that had pointers on flushing associated caches, etc. (I can get you the URL if you want it). And, of course, have done reboots after regedits, etc. I have not tried anything with paged pool memory, although I have found articles suggesting that may be a contributing factor, although it seems to show up more with large file transfers and backups which are not a problem for me.

Thanks for any additional thoughts.

hmm.. sounds like you've already been down several paths... will see if i can find anything else helpful....and, yes, if it's handy would appreciate the link to article you mention (if only for my own reference.) thx...

Thanks for looking further; the link is MSFT knowledgebase article Q304101 or 304101. It concerns Win2K, 2003 & NT 4.0 but I know a lot of that stuff can spill over to XP as well.

Well.. here are some thoughts and related info that is another approach (but just a guess on my part so proceed at your own risk).

From reading about IRPStackSize you may have noticed talk about its size being impacted by the number of “filter drivers” on the device. Every IO request for that device must go through its filter drivers and each takes IRP stack space to get through it. (Though at the same time can't help but think thjat an IRPStackSize of 50 is alot of space!)

I guess Norton must use several filter drivers as when their fix bulletin was published it discussed their filter drivers and IRPStackSize. The more filter drivers the larger IRPStackSize required.

So the thought is to try removing (or not load) any 3rd party services/drivers not required and see if makes any difference.

And here’s some resources I put together that might help with that approach

• Look here for a free tool to identify the filter drivers for a device
• MS KB: How to temporarily deactivate the kernel mode filter driver in Windows
• Use this handy tool to get an organized list of all the drivers (and services – make sure of which View you have) so you can also decide what might be uninstalled or not loaded

Like i said, don't know if it will make a difference but thought is worth a shot

/************** EDIT ***********************/
btw.. the driver filter tool also shows the driver version. I'd also double check you have most recent drivers of each one as a buggy driver that sometimes doesn't mark an I/O request as complete would certainly cause stack overflow as well

Thank you for the suggestions. Never had heard of filter drivers before so I will look into this and see if it helps. I think the closest I have heard to your suggestion is to try disabling startup programs/services, but I did not realize it had anything to do with filter drivers. Oddly enough, since it is a server, there are virtually no extra programs or services on it that are not absolutely necessary, but I will try.

OK. Let me know.

though even common maintenance software like disk defraggers and backup programs sometime use filter drivers (fyi). so worth taking a look. and of course checking version numbers for up to date.

/************* EDIT ****************/
Normally a device request goes to the driver which returns the result.

Filter drivers 'transparently" sit between the incoming request (upper filters) and the result returned (lower filters).
Transparent in that applications and normal device drivers needn't do anything different (or even know) that they are there or not.
Upper filters screen the incoming request and potentially modify it as it passes through.
Lower filters screen the outgoing device driver result and also may modify the result as it passes through
But not always completely transparent as e.g. they affect they IRPStackSize requirement for a device

DEVICE REQUEST
. ||
. \/
Upper Filters (can be zero or more)
. ||
. \/
Device Driver
. ||
. \/
Lower Filters (can be zero or more)
. ||
. \/
Results returned from DEVICE REQUEST