Capturing a Trace at Boot Up

Capturing a trace during a boot is a common task that can be difficult to accomplish. In fact the most fool proof way to capture all traffic at boot is to capture the traffic from a 3rd party capturing machine in promiscuous mode. But this requires you to mirror or span a port on your switch, or insert a simple hub into your network so that you can see the traffic from the booting machine. For Windows 7 and Windows 2008 R2, you might be better off using the Netsh /Capture=yes option (see Windows and Network Monitor Event Tracing). But there is another possibility using NMCap as a service which I will unveil to you now.

SRVANY and INSTSRV

These two old resource kit utilities can be used to start any application as a service. And while they were designed for XP and Win2003, I successfully installed and ran my tests on Vista as well. Keep in mind that there isn't much support available for these tools, and your millage might vary. The Windows 2003 resource kit which contains these tools is available here.

Generic instructions are available in this KB article which is what I used as a template. So you can reference it for more details.

The first step is to create a batch file that starts NMCap. I stored my batch file in c:\bootcap and configured NMCap to store the captures file in 5 Mbyte chunks in this same location. This way I can access each new capture as it is created. If you don't use chained captures, accessing them becomes tricky as you might not want, or be able, to stop NMCap when running as a service. I will talk to that a bit more in the next section.

My batch file consists of this one line:

 "c:\Program Files\Microsoft Network Monitor 3\nmcap" /network * /capture /file c:\bootcap\bootcap.chn:5M > "c:\bootcap\out.txt"

Feel free to test and see that it works properly by running at a command prompt before moving to the next steps.

Now that I have a working NMCap batch file, we follow the instructions in the referenced KB and set up this batch file as a service. I followed these steps.

1. At an elevated command prompt type the following, where path points to the location of the resource kit tools:

path\INSTSRV.EXE NmCapBoot path\SRVANY.EXE

2. Edit the Registry to add the application path. I'll echo the warning in the KB about messing with the Registry. If you don't know what you are doing, be careful and do a backup if you are fond of this machine.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NmCapBoot

3. From the Edit menu, click “Add Key”. Type the following and click OK:

Key Name: Parameters

Class : <leave blank>

4. Select the Parameters key.

5. From the Edit menu, click “Add Value”. Type the following and click OK:

Value Name: Application

Data Type : REG_SZ

String : c:\bootcap\c.cmd

6. Close Registry Editor.

You now have a service that will start automatically on reboot. You can also manually start it right now by typing "Net Start NmCapBoot" at the command prompt. This is a good step to prove everything is working. Check the output of c:\bootcap\out.txt to make sure there aren't any problems. Also verify that a capture file gets created. You will see the bootcap.cap appear, but it is not accessible until you fill the first 5 Mbytes and the next chained capture file is created. I find viewing a video on the web is one easy way to achieve this. Once you see bootcap(1).cap get created, you should be able to access the first file, bootcap.cap.

Properly Stopping your Capture

One problem with this method is that shutting the service down with "Net Stop NmCapBoot" doesn't properly close NMCap. No capture file will be created for the last chuck of trace data in the buffer that hasn't already been written to a capture file. In fact, stopping the service with "Net Stop" will leave NMCap running. So you'll have to use Task Manager, select "show processes from all users", and stop NMCap manually.

If there's no easy way to kill the capture, then you might need to trigger the capture to stop. However using a filter requires you load the parsers, which won't work as our installed parsers can’t be compiled and loaded to the non-user account running the service. Also filtering is expensive, as we have to parse the frame, so frames might be dropped on a speedy network and/or low disk space.

One simple solution to both problems is to create some simple parser code with NPL and provide an Offset, Length, Pattern type of match instead. This parsing is much quicker and the parser code to support this is trivial. So create a new sparser.npl text file and place this in c:\bootcap which will be accessed by using the /SetNPLPath parameter with NMCap.

 
UnsignedNumber blob(n)
{
    Size = n;
}

Protocol Frame
{
}

This lets you type a filter like "blob(FrameData, 30, 4)==0x01020304". This particular offset on my network is the IPv4 Destination address for ICMP. Now you can stop NMCap by running "ping 1.2.3.4", though keep in mind you still need to stop the service with the Net Stop command. Mind you could come up with other patterns to stop the trace if the ping doesn't work for you.

Your new batch file, c.cmd, looks like this:

 "c:\Program Files\Microsoft Network Monitor 3\nmcap" /SetNPLPath c:\bootcap
"c:\Program Files\Microsoft Network Monitor 3\nmcap" /network * /capture /file c:\bootcap\bootcap.chn:5M /stopwhen /frame blob(FrameData, 30, 4)==0x01020304> "c:\bootcap\out.txt"

This actually calls NMCap twice. The difference is that the first time we set a new NPL path to our sparser.npl which we put in the root of the c:\bootcap directory. This tells NMCap to rebuild and save this as the parser set to use.

Consequently, this changes the parser path for all instances of the UI and NMCap, so you'll have to revert this change if you need to use the normal parsers on this machine. In the UI, you can do this by going to tools, options, from the menu and opening the parsers tab. Then select the Restore Defaults button and follow that by pressing the Save and Reload Parsers button to rebuild the restored default parser set.

Using Alternate Stop Patterns

In the example above, we use the blob type to specify the frame data as the first parameter and then the offset and size. So you can provide a different offset and size if you need to use a different type of frame to stop your trace. The easiest way to do this is to look at an existing trace and use the Offset and Selected Bytes displayed in the Hex details. Then you can create a display filter using the notation above to test and make sure you are triggering the right frame.

Here are a few more examples with offsets. Keep in mind these offsets are specific to my network which is IPv4 on Ethernet for these examples.

 

Pattern Description	Blob Filter	Command to Stop
ICMPv4 Length - Use the length of IPv4 and the fact that IPv4.NextProtocol is ICMP	"blob(framedata, 16, 2)==0x97 AND blob(framedata, 23, 1)==1"	ping /l 123 /n 1 1.2.3.4
ICMPv4 Data - Search for the "abcd" pattern	blob(framedata, 42, 4)==0x61626364	ping /n 1 1.2.3.4
DNS Name Pattern Match - look for the name "stopme" at a particular offset	blob(framedata, 55, 6)==0x73746F706D65	Nslookup stopme

Caveats and Pitfalls

Captures Can Get Overwritten - Since we are using the same NMCap command line, restarting the service or a reboot will cause capture files to get over written.

Service Start Dependencies - What if the service that sends traffic starts before the NMCapBoot service? In some cases you must set the dependencies of other services to wait for NMCap to start running. Another consideration is that NMCap might also depend on some services, like the capture driver. If you are not capturing the information you want, you may have to play around with the dependencies for the services installed on your machine and OS.

Can't Apply Capture Filter - As we mentioned above we don't have access to the full parser set in this configuration. You could solve this problem other ways, like copying the parsers somewhere and pointing directly to them. However, this is still a problem of performance which you will have to gauge yourself. A simple test is to run NMCap with your filters and watch the pending count during high traffic. If the pending count continues to grow, then you might not be able to keep up with the traffic.

Unable to Stop with Ping - There may be situations when you can't provide a ping to stop the trace. For instance if you wanted to trace a shutdown of a machine, it might be difficult to get NMCap to stop properly thus losing the frames you want to see.

SrvAny Saves the Day

Srvany and InstSrv allow for a unique way to run NMCap as a service to capture logon/logoff type traffic OR longer term monitoring across logins. Using the steps above should provide you with enough information to solve this difficult capturing scenario.

Comments

• Anonymous
  January 01, 2003
  thanks

• Anonymous
  December 28, 2011
  Voila ! that is what I was looking for. thanks

• Anonymous
  March 09, 2014
  You probably wonder why that could be a big deal. Usually clients not doing LDAPs are the ones we worry

• Anonymous
  November 19, 2014
  Great documentation, tested on Windows 7 and is working!
  

• Anonymous
  February 11, 2015
  ¡Hola de nuevo! ¿Echabais de menos a Network Monitor? ¿Os supo a poco el anterior

• Anonymous
  February 11, 2015
  ¡Hola de nuevo! ¿Echabais de menos a Network Monitor? ¿Os supo a poco el anterior