Dear Support we have a windows 2008 r2 hosting cluster services, yesterday the server had a BSOD with Bug Check code with 9e, i have used aBlue Scrren Viewer Utility to investigate more a round the problem and i have gor this File Name:netft.sys Address In Stack : netft.sys+26a5 after some browing i found this article : http://blogs.technet.com/b/dip/archive/2011/05/04/win2008r2-stop-0x9e-netft-netftwatchdogtimerdpc-b9-user-mode-health-monitor-related-to-iscsi.aspx could you please help me on this issue as i dont know what to do

We are having this same issue on only one of our two Hyper-V hosts as well. Any luck with this yet? It's happening about once a month or so.

If you are using broadcom nics and using bacs, try upgrading your nic drivers and bacs version, There was a bug when using tpc offload.

Hi A.Al-Haffar, Thanks for posting here. We generally need to analyze the memory dump files to locate the root cause. Unfortunately, debugging is beyond what we can do in the forum because of the nature of forum support. A support call to our product service team is needed for the debugging service. I'd like to recommend that you contact Microsoft Customer Support Service (CSS) for assistance so that this problem can be resolved efficiently. To obtain the phone numbers for specific technology request please take a look at the web site listed below: http://support.microsoft.com/default.aspx?scid=fh;EN-US;PHONENUMBERS If you are outside the US please see http://support.microsoft.com for regional support phone numbers. Thanks Tiger Li Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. I dont think this is an appropriate awnser. I hate when someone asks for help, and the response is to call support. I think we know when to call support, but we tend to look for help first. Also marking your own response as the awnser when it dose not address the issue is lame, it makes Microsoft staff look bad...

We also had that problem, but for that we used a tool called Windbg included in the debugging tools for windows. There we saw the same error but with some extra information. Saying about a TimerExpiration and a WatchdogTimerDpc, Process_Object fffffa801490f420 and DEFAULT_BUCKET_ID=DRIVER_FAULT_SERVER_MINIDUMP. But we haven't found anything else.

Did anyone get this BSOD 0x9e for netft.sys solved or we need to wait until microsoft issues a hotfix for netft.sys and msiscsi.sys drivers?

We found it was related with some linux corrupting the arp tables of our switches, what expanded to the internal switches of the blades which ended in BSOD. This happened only with a particular version of the driver (for a Broadcom nic) on our HS22 IBM Blade and Windows 2008 R2 SP1.

Exact same issue happening to us here. Did you ever get this resolved A. Al-Haffar? Can you please share the steps to fix if you have. Would be greatly appreciated.

We are also seeing this issue. Please report fix if you've found one. Thanks!

We are also experiencing this issue on one of our Hyper-V hosts. Has anyone found a good resolution to this issue? If so, please post the resolution. Thank you very much.

While I understand forums arent really suited to dump analysis, I wholeheartedly agree that contacting support should not be the first and only answer. I'm having the same issue on multiple nodes, in separate cluster environments. All W2K8 R2 SP1. It seems like it has cropped up over the past couple of weeks. We were forced in to a compliance hardening that required we catch up on updates, so of course, our environment was blasted with myriad untested updates which I fear may have exacerbated the issue. We're not running HyperV on these boxes. If you want to read up on it (http://blogs.technet.com/b/askcore/archive/2009/06/12/why-is-my-2008-failover-clustering-node-blue-screening-with-a-stop-0x0000009e.aspx) It sounds like a perfectly normal function of the cluster, and I understand its purpose, but my problem is that I can't determine which user-mode component (or series of components) is handling the heartbeat in order to know how to best proceed. I dont want to just knee-jerk turn it off or event it. I get that the countdown timeout (default 60 seconds) is exceeded, but what is it exactly that is dialoguing in this process? If it's exposed in any meaningful way I might be able to resolve it rather than just altering the default HangRecoveryAction (default - BugCheck to force failover) to sidestep the actual problem, that would be awesome. In digging in the DMP, it basically tells me what I already know - that the cluster service thought the box was hosed and forced a failover through 0x9e bugcheck. What irritates me is that that only half answers the question - I know why the box rebooted, because the CLuster Service timed out and invoked the KeBugCheckEx routine. Ok, so if thats the case....Why Did the Cluster Service Time out? Seems like a logical next step. I'm speculating the the Cluster Virtual Adapter (netft.sys) may have stopped responding to the Cluster Service, maybe... I just don't know where to go from there. BLueScreenView Bug Check Code: 0x0000009e Param1: fffffa80`3b188b30 (Process that failed to satisfy within the configured timeout) Param2: 00000000`0000003c (Health Monitoring Timeout - default value 3c=60seconds) Param3: 00000000`00000000 Param4: 00000000`00000000 Caused by Driver: netft.sys Caused by Address: netft.sys+26a5 WinDBG SYMBOL NAME: netft!NEtftWatchDogTimerDPC+b9 MODULE_NAME: netft IMAGE_NAME: netft.sys Ive opened a case with Microsoft to see if theres anything else I can learn about these. This particular seem relatively commonplace in r2 Failover clusters with HyperV installed, especially prior to W2K8R2 Service Pack 1, which included a couple of tangentially related hotfixes for this issuehttp://support.microsoft.com/kb/2135160,http://support.microsoft.com/kb/2520235). Will Update.