Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are hosting a 3rd-party app on a Windows workstation and we are receiving window degredation / zero window at the receive window, which is not justified by any communication behind the box.

We've tried using perfmon and look for resource degradation, but if you don't have large enough resource degradation to justify it, you can't prove which app process is behind it. The app we are examining does not have a debug mode to prove this.

The processor goes to 100%, but there's no disk activity to justify it; disk utilization is idle, but the processor is spinning. Perfmon did not provide a specific thread to justify it.

I am looking for a tool that could be applied to a Windows server and when there's a zero windowing situation or queue degradations are occurring. We feel this is an application listener injestion issue, but need more a granular tool to check this. Process monitor doesn't do this for us; is there a Windows tool akin to Snap Kit on Unix?

The application in question resides on a workstation and listens for and receives a couple thousand files (at most 100k, more likely 30k) from an external provider. It writes these received files to a file share via UNC. We have several similar instances of this application on other workstations and they are running fine, but they are listening to different client file transmitters. We've the client transmitters between 2 different workstations and the previously failing workstation ran fine with the new client and the previously fine workstation ran terribly when it was assigned what we've determined to be the problem client. We're fairly sure the problem is with the transmitting client sending to our workstation(s), but in the meanwhile we wanted to be able to narrow down precisely what the server is seizing on, and to do that we wanted more granularity in our tools.

UPDATE/NOTE: I'm a question-asking proxy for a non-internet-proactive team, so when questions are asked of me by you, I'll go back to them, get answers, and reiterate them here. Unless there's a further incident, I won't be in communication with said team until Monday, so I won't be able to provide most answers until Monday afternoon. I will, however, maintain a list of questions I need to provide answers for:

Current questions from you that I need to get answers for

  1. Check if ProcessExplorer or ProcessMonitor from SysInternals would work.
  2. Specify exact Windows version with SP.
  3. Where is the Zero Notification coming from (WireShark? (I'd actually like to say WireShark since we use that, but I won't give you definitive till I ask)).
  4. On incident, does the whole machine become unresponsive from a TCP/IP perspective?
share|improve this question
would process explorer from sysinternals do it? – SpacemanSpiff Feb 23 '13 at 15:41

You don't specify which version of Windows you're using, or Service Pack level.

Are you seeing the Zero Window notification from wireshark, or similar? Presumably when the app starts misbehaving, the whole machine becomes unresponsive from a TCP/IP perspective?

Also, what is the nature of the app? Presumably it's talking to something. Does it predominantly send data or receive data?

SpacemanSpiff's suggestion of Process Explorer is a good one in terms of seeing current statistics (performance, I/O, threads, Etc). However, I'd take a look at another SysInternals tool - Process Monitor. This'll let you see TCP/IP activity (not packet inspection), and will let you see if you're getting problems with SYN packets, Etc.

share|improve this answer
I've updated the post with more information regarding our situation and will maintain a list of questions I need to ask our team. – JoshDM Feb 23 '13 at 17:49
Having read your update, I'd certainly be looking at the TCP/IP monitoring side of Process Monitor ( I reckon you might be getting a lot of inbound SYN packets, with subsequent outbound SYN packets, but no inbound ACK (acknowledgement) packets. Now, the conversations in this "pending" state should timeout, but I wonder if you're getting flooded quite aggressively (aka SYN flood). – Simon Catlin Feb 25 '13 at 20:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.