Advanced Topics

Capturing High Volume Traffic

When capturing data from a large and busy network segment, you should keep in mind that processing thousands of packets per second may considerably increase the CPU usage and make the application less responsive. The best way to optimize the program's performance is to use rules to filter out the packets you don't need to monitor. For example, sending a 50 MB file between two machines on your LAN can generate approximately 40,000 NetBIOS packets with the data transfer rate of 10 MBytes per second, which can be a heavy load for the application. But normally you don't to need to view every NetBIOS packet being sent, so you can configure CommView to capture IP packets only. CommView has a flexible system of filters, and you can fine-tune the application to display only the packets that you really need. Also, if you are interested in the statistics information only (those green histograms, pie charts, and hosts tables), you can use the "Suspend packet output" menu command, which allows you to have statistical data without real-time packet display.

The factors that improve the program's performance:

Working with Multiple Instances

CommView can capture packets from several network adapters simultaneously. This feature is turned on by checking the Allow Multiple Application Instances checkbox in Settings => Options => Miscellaneous. Please note that you cannot open the same adapter in two different instances of the program. The same limitation applies to the Terminal Server: two users (local or remote) cannot capture traffic from the same adapter by running two instances of CommView on the same server.

Running CommView in Invisible Mode

There are two ways to run CommView as a hidden process:

  1. Launch CommView with the "hidden" switch, i.e.:
    CV.EXE hidden
  2. If CommView is already running, you can hide/unhide it by using the "hot key". To hide the application, press ALT+SHIFT+h. To unhide the application, press ALT+SHIFT+u.

Remember that you cannot completely hide any Windows application. When running in invisible mode, one can still see the CommView process in Task Manager.

Command Line Parameters

You can use command line parameters to perform the following operations when the program is being launched:

To connect to multiple Remote Agents from the same CommView instance, first make sure that multiple CommView instances are not allowed in the application options, and then use a batch file that should look like this:

START "CV" "C:\Program Files\CommView\CV.exe"
PING -n 1 -w 5000 >NUL
START "CV" "C:\Program Files\CommView\CV.exe" /ra "pwd1" 2
PING -n 1 -w 1000 >NUL
START "CV" "C:\Program Files\CommView\CV.exe" /ra "pwd2" 1
PING -n 1 -w 1000 >NUL
START "CV" "C:\Program Files\CommView\CV.exe" /ra "pwd3" 1
PING -n 1 -w 1000 >NUL

This script launches CommView, waits for 5 seconds to make sure that the application is loaded (we use the PING command to pause because there is no direct way of telling a .BAT file to pause), then we pass to the application the IP addresses, passwords, and adapter numbers of three Remote Agents (with one-second pauses).

You can use all of these parameters, except the last one, at the same time.

Exchanging Data with Your Application

CommView provides a simple TCP/IP interface that allows you to process packets captured by CommView using your own application in real time. Starting with version 5.0 you may also use this interface for sending packets (similar to the Packet Generator function in CommView).

Please note that the data format has changed compared to the previous versions of CommView. The TS switch has also been eliminated as all the information about a packet including the timestamp is now sent in the header.

How It Works

CommView should be launched with a special command-line argument, "MIRROR", that tells the program to mirror captured packets to an IP address and TCP port of your choice.


CV.EXE mirror: // mirrors packets to the loopback address, TCP port 5555
CV.EXE mirror: // mirrors packets to, TCP port 10200

When CommView is launched with a switch like this, it tries to establish a TCP session by connecting to the specified IP address and port number. It means that you should already have your application running and listening on the specified port. If CommView fails to establish a connection, it will keep on trying to connect every 15 seconds. The same happens if the connection is broken: CommView will try to re-establish it every 15 seconds. If the connection is successfully established, CommView sends the packets it captures to the specified IP address as they arrive, in real time.

Data Format

The data is transmitted in NCF format. Please refer to the CommView Log Files Format chapter for the format description.

Sending Packets

Packets may not only be received by your application, but also sent as if you were using Packet Generator. Data can be sent to CommView using the same TCP connection over which you are receiving the data. The data format is simple: You should send the packet length (a two-byte unsigned integer in the standard little-endian byte order) followed by the packet itself. If the adapter is not opened or it does not support packet injection, the packet is silently discarded.

Sample Projects

Two simple demo applications that listen for inbound connections, extract packets from the stream, and display raw data are available.


When mirroring data to a remote computer, make sure that the link between CommView and the computer to which the data is being mirrored is fast enough to transfer all the data being captured. If CommView captures 500 Kbytes/sec, and your link can handle only 50 Kbytes/sec, you'd inevitably have "traffic jams", which might result in various problems (e.g., Winsock may just stop sending data under some Windows versions). If you are looking for a more flexible solution that would feature smart buffering and remote control, consider using CommView Remote Agent.

Custom Decoding

CommView allows you to use two types of your own custom decoders.

Simple Decoder

If you implement this type of decoder, the output of your decoder will be displayed in the additional column in the Packets tab. Your decoder must be a 32-bit DLL file named "Custom.dll" that exports the only procedure named "Decode". The prototype of this procedure is shown below in C and Pascal:

extern "C" {
  void __stdcall Decode(unsigned char *PacketData, int PacketLen, char *Buffer, int BufferLen);
procedure Decode (PacketData: PChar; PacketLen: integer; Buffer: PChar; BufferLen: integer); stdcall;

The DLL must be located in the CommView application folder. When you launch CommView, it looks for "Custom.dll" in the application folder and loads it into memory. If the "Decode" entry point is found, CommView adds a new column named "Custom" to the packet list.

When a new packet is captured and is about to be displayed, CommView calls the "Decode" procedure and passes the packet contents to the DLL. The "Decode" procedure must process the packet data and copy the result to the supplied buffer. The first argument is the pointer to the packet data, the second argument is the data length, the third argument is the pointer to the buffer where the results of your decoding must be copied to, and the forth argument is the buffer size (currently always 1024 bytes). The buffer is allocated and freed by CommView, so don't attempt to reallocate or free it. The result that you copied to the buffer will be displayed as a string in the "Custom" column.

Your procedure must be fast enough to handle thousands of packets per second; otherwise it may slow down the application. Don't forget to use the STDCALL calling convention.

Two demo DLLs are available. They demonstrate a very simple operation: The output of the "Decode" function is the hex code of the packet's last byte. Your own decoder can be as complex as you wish.

Complex Decoder

If you implement this type of decoder, the output of your decoder will be displayed as additional items in the packet decoder tree. For information on the implementation of this decoder, please download the following file:

This type of decoder can be written in Microsoft Visual C++ only, as it is built using C++ classes.

Technical Support

Technical support for custom decoders is provided on the "best effort" basis. We may not be able to answer your programming-related questions.

CommView Log Files Format

CommView and CommView for WiFi use the data format described below for writing captured packets to .NCF files. This is an open data format that you can use for processing log files generated by CommView in your applications, as well as for exchanging data with your application directly (this method is described in this help file).

The packets are recorded consecutively. A 24-byte header, the structure of which is given below, prepends each packet body. All header fields with the length exceeding 1 byte use little-endian byte order.

Field name Length (bytes) Description
Data Length 2 The length of the packet body that follows the header
Source Data Length 2 The original length of the packet body that follows the header (without compression). If no compression is being used, the value of this field is equal to the value of the previous field.
Version 1 Packet format version (0 for the current implementation)
Year 2 Packet date (year)
Month 1 Packet date (month)
Day 1 Packet date (day)
Hours 1 Packet time (hours)
Minutes 1 Packet time (minutes)
Seconds 1 Packet time (seconds)
Microseconds 4 Packet time (microseconds)
Flags 1 Bit flags:
Medium 0...3 Medium type for the packet (0 - Ethernet, 1 - WiFi, 2 - Token Ring )
Decrypted 4 The packet has been decrypted
(applicable to WiFi packets only)
Broken 5 The packet was corrupted, i.e. had the incorrect CRC value (applicable to WiFi packets only)
Compressed 6 The packet is stored in compressed form
Reserved 7 Reserved
Signal Level 1 Signal level in percents
(applicable to WiFi packets only)
Rate 1 Data transmission rate in Mbps multiplied by 2
(applicable to WiFi packets only)
Band 1 Transmission band. 0x01 for 802.11a, 0x02 for 802.11b, 0x04 for 802.11g, 0x08 for 802.11a-turbo, 0x10 for 802.11 SuperG, 0x20 for 4.9 GHz Public Safety, 0x40 for 5 GHz 802.11n, 0x80 for 2.4 GHz 802.11n.(applicable to WiFi packets only)
Channel 1 Channel number
(applicable to WiFi packets only)
Direction 1 For non-WiFi packets, packet direction. 0x00 for pass-through, 0x01 for inbound, 0x02 for outbound. For WiFi packets, the high order byte for the packet rate, if the one-byte Rate field cannot accommodate the value (i.e. the value is higher than 255).
Signal Level (dBm) 1 Signal level in dBm (applicable to WiFi packets only)
Noise Level (dBm) 1 Noise level in dBm (applicable to WiFi packets only)
Data Packet body (unmodified, as transmitted over the media). If the compression flag is set, the data is compressed using the publicly available Zlib 1.1.4 library. The length of this field is recorded in Data Length.

The total header length is 24 bytes.

If packets are stored in the compressed form, the Data Length field contains the length of data after compression, whilst the Source Length field contains the original data length. If a packet is uncompressed, both fields contain the same value.