Bill: Naturally. Especially when we get a call from a user trying to locate the "any" key.

Scott: But to give the users some credit, workstation lockups often can be traced to events that happen "on the wire."

Bill: These days, network adapters, drivers and operating systems should be able to handle virtually everything the network throws at them, including garbage packets, broadcast storms, duplicate packets (retransmissions), and so on.

Scott: These subsystems have become more reliable over the years, but they still have their bad days.

Bill: As network analysts, we're often faced with the task of determining where big problems like workstation lockups are really happening--network or not.

Scott: In our client's case, the lo ckup was fairly severe in that the hourglass persisted and the Windows95 task manager wouldn't activate wh en pressing Ctrl-Alt-Delete.

Bill: Before ripping out drivers and adapters, or upgrading to Windows NT, we set out to capture packets from workstations that were likely to fail.

Scott: Our goal was to analyze several packet traces both before and after a workstation failure. We began by setting our analyzer's capture filters to the user's workstation addresses and then asked the users to notify us as soon as their applications failed.

Bill: After repeating this process a number of times, we had the evidence we needed.

Scott: Upon closer examination of a number of packet traces, it became apparent that there were two distinct situations when a workstation would hang.

Bill: In the first situation, the workstation asked for data from a SQL server, which would acknowledge the request, but fail to send the actual data.

Scott: In the second situation, the workstation asked for data and received it, yet still locked up.

Bill: In the first situation, we saw that the server received a SQL statement requesting information from a database and acknowledged it (with a TCP ack), but never responded with information.