WinSock Errors Test

In computing, the Windows Sockets API (WSA), which was later shortened to Winsock, is a technical specificatio that defines how Windows network software should access network services, especially TCP/IP. It defines a standard interface between a Windows TCP/IP client application (such as an FTP client or a web browser) and the underlying TCP/IP protocol stack.

The WinSock Errors test scans the Windows event logs for winsock-related errors and reports the count of such errors.

Target of the test : A Citrix XenApp server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the Client that is to be monitored

Configurable parameters for the test
TEST PERIOD - How often should the test be executed Host - The host for which the test is to be configured Port – Specify the port at which the specified HOST listens to. By default, this is 8080. logtype – Refers to the type of event logs to be monitored. The default value is Microsoft-Windows-Winsock-AFD/Operational. policy based filter- Using this page, administrators can configure the event sources, event IDs, and event descriptions to be monitored by this test. In order to enable administrators to easily and accurately provide this specification, this page provides the following options: Manually specify the event sources, IDs, and descriptions in the FILTER text area, or, Select a specification from the predefined filter policies listed in the FILTER box For explicit, manual specification of the filter conditions, select the NO option against the POLICY BASED FILTER field. This is the default selection. To choose from the list of pre-configured filter policies, or to create a new filter policy and then associate the same with the test, select the YES option against the POLICY BASED FILTER field. filter - If the POLICY BASED FILTER flag is set to NO, then a FILTER text area will appear, wherein you will have to specify the event sources, event IDs, and event descriptions to be monitored. This specification should be of the following format: {Displayname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded}. For example, assume that the FILTER text area takes the value, OS_events:all:Browse,Print:all:none:all:none. Here: OS_events is the display name that will appear as a descriptor of the test in the monitor UI; all indicates that all the event sources need to be considered while monitoring. To monitor specific event sources, provide the source names as a comma-separated list. To ensure that none of the event sources are monitored, specify none. Next, to ensure that specific event sources are excluded from monitoring, provide a comma-separated list of source names. Accordingly, in our example, Browse and Print have been excluded from monitoring. Alternatively, you can use all to indicate that all the event sources have to be excluded from monitoring, or none to denote that none of the event sources need be excluded. In the same manner, you can provide a comma-separated list of event IDs that require monitoring. The all in our example represents that all the event IDs need to be considered while monitoring. Similarly, the none (following all in our example) is indicative of the fact that none of the event IDs need to be excluded from monitoring. On the other hand, if you want to instruct the eG Enterprise system to ignore a few event IDs during monitoring, then provide the IDs as a comma-separated list. Likewise, specifying all makes sure that all the event IDs are excluded from monitoring. The all which follows implies that all events, regardless of description, need to be included for monitoring. To exclude all events, use none. On the other hand, if you provide a comma-separated list of event descriptions, then the events with the specified descriptions will alone be monitored. Event descriptions can be of any of the following forms - desc, or desc, or desc,or desc, or desc1desc2, etc. desc here refers to any string that forms part of the description. A leading '' signifies any number of leading characters, while a trailing '' signifies any number of trailing characters. In the same way, you can also provide a comma-separated list of event descriptions to be excluded from monitoring. Here again, the specification can be of any of the following forms: desc, or desc, or desc,or desc, or desc1desc2, etc. desc here refers to any string that forms part of the description. A leading '' signifies any number of leading characters, while a trailing '' signifies any number of trailing characters. In our example however, none is specified, indicating that no event descriptions are to be excluded from monitoring. If you use all instead, it would mean that all event descriptions are to be excluded from monitoring. By default, the filter parameter contains the value: all. Multiple filters are to be separated by semi-colons (;). Note: The event sources and event IDs specified here should be exactly the same as that which appears in the Event Viewer window. On the other hand, if the POLICY BASED FILTER flag is set to YES, then a FILTER list box will appear, displaying the filter policies that pre-exist in the eG Enterprise system. A filter policy typically comprises of a specific set of event sources, event IDs, and event descriptions to be monitored. This specification is built into the policy in the following format: {Policyname}:{event_sources_to_be_included}:{event_sources_to_be_excluded}:{event_IDs_to_be_included}:{event_IDs_to_be_excluded}:{event_descriptions_to_be_included}:{event_descriptions_to_be_excluded} To monitor a specific combination of event sources, event IDs, and event descriptions, you can choose the corresponding filter policy from the FILTER list box. Multiple filter policies can be so selected. Alternatively, you can modify any of the existing policies to suit your needs, or create a new filter policy. To facilitate this, a icon appears near the FILTER list box, once the YES option is chosen against POLICY BASED FILTER. Clicking on the icon leads you to a page where you can modify the existing policies or create a new one. The changed policy or the new policy can then be associated with the test by selecting the policy name from the FILTER list box in this page. usewmi- The eG agent can either use WMI to extract event log statistics or directly parse the event logs using event log APIs. If the USEWMI flag is YES, then WMI is used. If not, the event log APIs are used. This option is provided because on some Windows NT/2000 systems (especially ones with service pack 3 or lower), the use of WMI access to event logs can cause the CPU usage of the WinMgmt process to shoot up. On such systems, set the USEWMI parameter value to NO. On the other hand, when monitoring systems that are operating on any other flavor of Windows (say, Windows 2003/XP/2008/7/Vista/12), the USEWMI flag should always be set to ‘Yes’. stateless alerts - Typically, the eG manager generates email alerts only when the state of a specific measurement changes. A state change typically occurs only when the threshold of a measure is violated a configured number of times within a specified time window. While this ensured that the eG manager raised alarms only when the problem was severe enough, in some cases, it may cause one/more problems to go unnoticed, just because they did not result in a state change. For example, take the case of the EventLog test. When this test captures an error event for the very first time, the eG manager will send out a critical email alert with the details of the error event to configured recipients. Now, the next time the test runs, if a different error event is captured, the eG manager will keep the state of the measure as critical, but will not send out the details of this error event to the user; thus, the second issue will remain hidden from the user. To make sure that administrators do not miss/overlook critical issues, the eG Enterprise monitoring solution provides the stateless alerting capability. To enable this capability for this test, set the stateless alerts flag to Yes. This will ensure that email alerts are generated for this test, regardless of whether or not the state of the measures reported by this test changes. DD Frequency- Refers to the frequency with which detailed diagnosis measures are to be generated for this test. The default is 1:1. This indicates that, by default, detailed measures will be generated every time this test runs, and also every time the test detects a problem. You can modify this frequency, if you so desire. Also, if you intend to disable the detailed diagnosis capability for this test, you can do so by specifying none against DD FREQUENCY. DETAILED DIAGNOSIS - To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enabled/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
Send errors:	Indicates the number of send errors captured by the event log during the last measurement period.	Number	The send function and WSAsend functions send data on a connected socket. The value of this measure will be incremented when errors are returned on failed send and WSAsend requests. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what send errors occurred. Typically, event IDs 1003, 1005, 1007, 1011, 1013, and 3007 are classified as send errors.
Receive errors:	Indicates the number of receive errors captured by the event log during the last measurement period.	Number	The recv, WSARecv, and WSARecvEx functions receive data from a connected socket or a bound connectionless socket. If the recv, WSARecv, and WSARecvEx requests fail and return errors, such errors are captured by the event log. The value of this measure represents the count of these errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what receive errors occurred. Typically, event IDs 1004, 1006, 1009, 1012, 1015 are classified as receive errors.
Connect errors	Indicates the number of connect errors captured by the event log during the last measurement period.	Number	The connect, ConnectEx, WSAConnect, WSAConnectByList, or WSAConnectByName functions typically establish a connection to a specified socket. If calls to these functions fail owing to errors, such error events are captured by the event logs. The value of this measure denotes the count of such errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what connect errors occurred. Typically, event IDs 1017, 1018, 1020, 1021, 3006 are classified as connect errors.
Accept errors:	Indicates the number of accept errors that occurred during the last measurement period.	Number	The accept, AcceptEx, and WSAAccept functions permit an incoming connection attempt on a socket. If calls to any of these functions fail, then the errors causing the failures are captured by the event logs. The value of this measure denotes the count of such errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what accept errors occurred. Typically, event IDs 1023, 1024, 1026, 1027 are classified as accept errors.
Bind errors:	Indicates the number of bind errors that occurred during the last measurement period.	Number	If the implicit or explicit binding of a socket handle fails, then errors causing the bind failure will be captured by the event logs. The value of this measure denotes the count of such errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what bind errors occurred. Typically, event IDs 1029 and 1030 are classified as bind errors.
Abort errors:	Indicates the number of abort errors that occurred during the last measurement period.	Number	An abort/cancel operation can be Winsock-initiated or transport-initiated. The value of this measure represents the count of both types of abort operations. A Winsock-initiated abort can occur due to the following reasons: An abort due to unread receive data buffered after close. An abort after a call to the shutdown function with the how parameter set to SD_RECEIVE and a call to the closesocket function with receive data pending. An abort after a failed attempt to flush the endpoint. An abort after an internal Winsock error occurred. An abort due to a connection with errors and the application previously requested that the connection be aborted on certain circumstances. One example of this case would be an application that set SO_LINGER with a timeout of zero and there is still unacknowledged data on the connection. An abort on a connection not fully associated with accepting endpoint. An abort on a failed call to the accept or AcceptEx function. An abort due to a failed receive operation. An abort due to a Plug and Play event. An abort due to a failed flush request. An abort due to a failed expedited data receive request. An abort due to a failed send request. An abort due to canceled send request. An abort due to a canceled called to the TransmitPackets function. A transport-initiated abort can occur if a reset is indicated by the transport. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to why aborts occurred. Typically, event IDs 1032 and 1033 are classified as abort errors.
Listen errors:	Indicates the number of listen errors that occurred during the last measurement period.	Number	Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what listen errors occurred. Typically, event IDs 1026 and 1037 are classified as listen errors.
Indication errors:	Indicates the number of indication errors that occurred during the last measurement period.	Number	An indicated operation can be: A connection indicated operation: This occurs when an application receives a connection request. A data indicated operation: This occurs when an application receives data on a connected socket. Data indicated from transport operations: This occurs when an application posts a receive request and receives data. Disconnect indicated from transport operations: This occurs when an application receives a disconnect indication. Errors in these processes are categorized under Indication errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what indication errors occurred. Typically, event IDs 3000, 3001, 3003, 3004 are classified as indication errors.
Other errors:	Indicates the number of other errors that occurred during the last measurement period.	Number	Errors that cannot be classified as send, receive, connect, accept, bind, abort, listen, or indication, will be grouped under Other errors. Ideally, the value of this measure should be 0. In case of a non-zero value, use the detailed diagnosis of this measure to know what other errors occurred. Typically, event IDs 1000,1001,1002,1035 are classified as other errors.