Microsoft KB Archive/303802

= How To Troubleshoot SMB Connections from IIS/ASP =

Article ID: 303802

Article Last Modified on 3/15/2006

-

APPLIES TO


 * Microsoft Internet Information Server 4.0

-



This article was previously published under Q303802



SUMMARY
This article shows how to gather the proper information to review the connection between an Internet Information Server (IIS) server and a Server Message Block (SMB) share.



MORE INFORMATION
This article assumes familiarity with Network Monitor, Internet Information Server, and the TCP/IP protocol.

To effectively troubleshoot issues relating to SMB file sharing, particularly in regard to change notification and Active Server Pages (ASP), the most useful information is a network trace of the file that is being requested off of the SMB share and evidence of a change with respect to that file.

To get a good network trace of SMB traffic for IIS/ASP stale content/permission issues do the following:
 * 1) Close all Windows Explorer and Microsoft Internet Explorer windows, and disconnect any mapped drives to the SMB share. Also close any cmd windows that are open to that share.
 * 2) Stop the IIS Admin service (net stop iisadmin).
 * 3) Under the Capture menu in Network Monitor, increase the buffer size.
 * 4) Use Network Monitor to start the capture.
 * 5) Restart the Web Publishing Service (net start w3svc).
 * 6) Request the test page from a browser, preferably from a computer that is not the IIS server.
 * 7) Connect to the SMB server and modify your test page. If possible, do this via telnet or locally, not though an SMB share.
 * 8) Refresh your test page in Microsoft Internet Explorer and stop the trace.

The following is a brief overview of how ISATQ.dll and ASP flush cached pages, and what information from the SMB server ASP/ISATQ is needed (and why) to purge a template from the cache.

In order for ASP to flush the ASP page, you need to get a success from the redirector with either a 0 for the parameter count or the size of the buffer that contains the file name or list of files. This information should be in the change notification packet sent by the Common Internet File System (CIFS)/SMB server. A 0 in place of the parameter count indicates that there are too many changes to list. Sending a list of files is preferred over sending 0 (all files), and this is the way that the Windows implementation of SMB handles this. Managing files in this way results in a performance increase in particular for ASP Session and Application State.

For illustration, in the Samba traces below the bits that indicate status and parameter count are all set to zeros, which causes ASP to fully flush the cache. This will result in performance degradation (including losing all sessions, and having the IIS application restart), but it will flush everything from the cache.

The following is an example of a change notification coming from Samba on Linux (Aug 14 2000/samba-2.0.7-21ssl, and RedHat 7.0). You will notice the bits are not all 0 but rather they are 0x10C 0x0. The translation of the packet by Network Monitor shows that 0x10c is STATUS_NOTIFY_ENUM_DIR. Thus the Samba computer is suggesting that you enumerate the directory but not send a file name or a file list. At this point it is up to the redirector to translate this packet and send the necessary notification up the chain to the destination process and file that this packet refers to.

As you can see in the SMB header, this change notification is destined for PID 0x03DC (in the case of the test, this was inetinfo). In this packet there is no file ID (FID). In SMB traces, an FID is assigned for each file. The best way to get the FID of the file in question is to see the ID as it is assigned by the redirector when the file is retrieved from the file system, as well as the process ID that needs the file. 14957 106.687500 SMBUNIX 00508BF1348F SMB R NT transact - NT error, System, Success, Code = (268) STATUS_NOTIFY_ENUM_DIR SMBUNIX WIN2KSRV IP Frame: Base frame properties Frame: Time of capture = 7/3/2001 23:29:45.187 Frame: Time delta from previous physical frame: 0 microseconds Frame: Frame number: 14957 Frame: Total frame length: 129 bytes Frame: Capture frame length: 129 bytes Frame: Frame data: Number of data bytes remaining = 129 (0x0081) ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol ETHERNET: Destination address : 00508BF1348F ETHERNET: .......0 = Individual address ETHERNET: ......0. = Universally administered address ETHERNET: Source address : 0060083194AD ETHERNET: .......0 = No routing information present ETHERNET: ......0. = Universally administered address ETHERNET: Frame Length : 129 (0x0081) ETHERNET: Ethernet Type : 0x0800 (IP: DOD Internet Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 115 (0x0073) IP: ID = 0x6B1F; Proto = TCP; Len: 115 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) IP: Precedence = Routine IP: Type of Service = Minimize Delay IP: Total Length = 115 (0x73) IP: Identification = 27423 (0x6B1F) IP: Flags Summary = 2 (0x2) IP: .......0 = Last fragment in datagram IP: ......1. = Cannot fragment datagram IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 64 (0x40) IP: Protocol = TCP - Transmission Control IP: Checksum = 0xDE97 IP: Source Address = 172.26.204.104 IP: Destination Address = 172.26.204.32 IP: Data: Number of data bytes remaining = 95 (0x005F) TCP: .AP..., len:  75, seq: 979481609-979481684, ack:4234385737, win: 2920, src:  139 (NBT Session)  dst: 1266 TCP: Source Port = NETBIOS Session Service TCP: Destination Port = 0x04F2 TCP: Sequence Number = 979481609 (0x3A61B409) TCP: Acknowledgement Number = 4234385737 (0xFC639949) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) TCP: Flags = 0x18 : .AP...       TCP: ..0..... = No urgent data TCP: ...1.... = Acknowledgement field significant TCP: ....1... = Push function TCP: .....0.. = No Reset TCP: ......0. = No Synchronize TCP: .......0 = No Fin TCP: Window = 2920 (0xB68) TCP: Checksum = 0x7BF9 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 75 (0x004B) NBT: SS: Session Message, Len: 71 NBT: Packet Type = Session Message NBT: Packet Flags = 0 (0x0) NBT: .......0 = Add 0 to Length NBT: Packet Length = 71 (0x47) NBT: SS Data: Number of data bytes remaining = 71 (0x0047) SMB: R NT transact - NT error, System, Success, Code = (268) STATUS_NOTIFY_ENUM_DIR SMB: NT status code = 0x10C, Facility = System, Severity = Success, Code = (268) STATUS_NOTIFY_ENUM_DIR SMB: NT Status Severity Code = Success SMB: NT Status Customer Code = 0 (0x0) SMB: NT Status Reserved Bit = 0 (0x0) SMB: NT Status Facility = System SMB: NT Status Code System Success = STATUS_NOTIFY_ENUM_DIR SMB: Header: PID = 0x03DC TID = 0x0005 MID = 0x1659 UID = 0x0072 SMB: Tree ID     (TID) = 5 (0x5) SMB: Process ID  (PID) = 988 (0x3DC) SMB: User ID     (UID) = 114 (0x72) SMB: Multiplex ID (MID) = 5721 (0x1659) SMB: Flags Summary = 136 (0x88) SMB: .......0 = Lock & Read and Write & Unlock not supported SMB: ......0. = Send No Ack not supported SMB: ....1... = Using caseless pathnames SMB: ...0.... = No canonicalized pathnames SMB: ..0..... = No Opportunistic lock SMB: .0...... = No Change Notify SMB: 1....... = Server response SMB: flags2 Summary = 16385 (0x4001) SMB: ...............1 = Understands long filenames SMB: ..............0. = Does not understand extended attributes SMB: ...0............ = No DFS namespace SMB: ..0............. = No paging of IO           SMB: .1.............. = Using NT status codes SMB: 0............... = Using ASCII strings SMB: Command = C NT transact SMB: Word count = 18 SMB: Word parameters SMB: Total Parameter Count = 0 (0x0) SMB: Total Data Count = 0 (0x0) SMB: Parameter Count = 0 (0x0) SMB: Parameter Displacement = 0 (0x0) SMB: Data Count = 0 (0x0) SMB: Data Offset = 0 (0x0) SMB: Data Displacement (NT) = 0 (0x0) 00000: 00 50 8B F1 34 8F 00 60 08 31 94 AD 08 00 45 10 00010: 00 73 6B 1F 40 00 40 06 DE 97 AC 1A CC 68 AC 1A 00020: CC 20 00 8B 04 F2 3A 61 B4 09 FC 63 99 49 50 18 00030: 0B 68 7B F9 00 00 00 00 00 47 FF 53 4D 42 A0 0C 00040: 01 00 00 88 01 40 00 00 00 00 00 00 00 00 00 00   00050:  00 00 05 00 DC 03 72 00 59 16 12 00 00 00 00 00 00060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   00070:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00080:  00

To use a debugger to see what ASP received from the redirector in regard to the change notification sent by the SMB server, set the following breakpoints. bp KERNEL32!ReadDirectoryChangesW bp asp!CASPDirMonitorEntry__ActOnNotification

Then, when you hit the ActOnNotification breakpoint, look at the first and second parameters. The first parameter is the status that the redirector is giving to ASP for the change notification. The second parameter is the number of bytes written. 0:008> g Breakpoint 0 hit eax=749f1db8 ebx=77db80bc ecx=017d3eb0 edx=74a30908 esi=017d3eb0 edi=00000000 eip=749fbe09 esp=0269feec ebp=0269ff4c iopl=0        nv up ei pl zr na po nc cs=001b  ss=0023  ds=0023  es=0023  fs=0038  gs=0000             efl=00000246 asp!CASPDirMonitorEntry__ActOnNotification: 749fbe09 55              push    ebp 0:032> kv ChildEBP RetAddr Args to Child 0269fee8 6d704302 0000003b 00000000 77e82ef1 asp!CASPDirMonitorEntry__ActOnNotification (FPO: [Non-Fpo]) 0269ff4c 6d70875d 017d3eb0 00000000 0000003b ISATQ!CDirMonitor__DirMonitorCompletionFunction+0xad (FPO: [Non-Fpo]) 0269ff80 6d708a25 0000003b 00000000 017d3ed0 ISATQ!AtqpProcessContext+0x262 (FPO: [Non-Fpo]) 0269ffb4 77e837cd 00000000 6d708735 00f6fc38 ISATQ!AtqPoolThread+0x1a8 (FPO: [EBP 0x0269ffec] [1,4,4]) 0269ffec 00000000 6d70887d 00000000 00000000 KERNEL32!TlsSetValue+0xf0 (FPO: [Non-Fpo]) 0:032> ?3b Evaluate expression: 59 = 0000003b 0:032> * ERROR_UNEXP_NET_ERR             59L 0:032> *dwStatus = 0x3b (59) dwBytesWritten = 0 (none) 0:032> *so, apparently the status that it returned is something the RDR considers an error

ISATQ and ASP consider different status codes from the redirector the limit for when an item is to be flushed from the cache. ASP requires that the status be success and the number of bytes be 0 before it will flush the entire directory of files cached. This is because that would require you to flush the Global.asa, which would result in termination of all sessions, and the application would restart. ISATQ is not as strict when it comes to cached HTM pages.

