Troubleshooting

Explaining aspects that are not seen but taken care of. Use these tips to optimize your NetCrunch resilience.

Our goal with NetCrunch is to provide a practical, reliable solution that works in real-world environments. We’ve built it to be resilient and self-reliant, designed to help IT professionals manage complex networks without unnecessary hassle or false promises.

NetCrunch is engineered to be trouble-free. It undergoes extensive testing and follows a development process aimed at minimizing defects. However, as industry experts know, even the best practices can only detect 75% to 90% of bugs before release - a reality confirmed by decades of research. Network monitoring software like NetCrunch must also handle countless edge cases caused by the wide variety of vendor devices and technology implementations it interacts with.

Networks are inherently complex, often relying on technologies defined by RFC documents that vendors don’t always fully implement. This is particularly evident with protocols like SNMP and NetFlow. On top of that, operating systems such as some versions of Windows Server sometimes contain unresolved bugs in components like WMI. NetCrunch is built to navigate these challenges, delivering dependable performance for IT teams working in demanding environments.

Releases

To address various issues and bugs in the software, we release NetCrunch minor releases several times a year. These releases can be installed over previous versions, and they usually do not change the data format. Read Update, Migrate and Backup .

Issue Sources

Based on our experience, issues are coming from a limited number of sources. Let us explain where the problems come from and how you can correct them quickly, or help us to fix them for you.

Configuration

Most monitoring issues are caused by invalid configuration. There is no way for NetCrunch to connect to servers with wrong or missing OS credentials or wrong SNMP profiles (communities or passwords).

NetFlow

There is a range of protocols based on NetFlow implemented by various vendors. They usually conform to the NetFlow v5 protocol. Each device has specific settings, and starting from NetFlow v9, data contained in the flows depends on the configuration. First, you need to set up the device to send data to NetCrunch – there is a range of articles about NetFlow configuration on the Internet.

If NetCrunch cannot decode the flow data, you need to capture such data with Wireshark and send it to us. Sometimes the devices have bugs in their NetFlow implementations. Although we can’t fix them, sometimes we can go around and accept invalid data.

SNMP MIBs

More than 10,000 MIBs are circulating on the Internet. As there is no standard for MIB compiler (standard MIBs were defined only in RFC documents), it is somewhat hard to compile them. They were often written once and never checked, or compiled with a specific compiler in a particular environment.

Usually, the source of MIB problems is the wrong syntax or a missing module that some MIBs may depend on. This kind of issue can often be fixed by specifying the module name alias.

If you are not familiar with MIBs and can’t solve these problems, contact our support – we will try to find a solution. We already compiled over 8700 MIBs, so there is a chance we can handle some more...

Windows

Windows is a complex system. It’s built by setting layers on top of another layer. The easiest way to manage Windows configuration is by Active Directory. But we know that in real life, there are many unlinked systems and Windows versions.

Problems with Windows (Windows 7/2008 or later) are always related to Windows settings. See Windows Monitoring Setup. Monitoring of a workgroup Windows 7 workstation is easy with a built-in local Administrator account.

Although we know that it is possible to monitor remote systems with lower than administrative rights, we can't give you the recipe that is universal across all Windows versions. Simply, it sometimes works, and sometimes not - systems that appear to be configured the same way behave differently.

NetCrunch Performance Limits

There are always some limitations to NetCrunch.

Licensing

it may not impose limits on the number of nodes being monitored. In our tests, we've got to 25,000 nodes, but the program can choke with a lower number of nodes depending on what you are monitoring in real life.

Hardware

such as memory, disk, and network, set the ultimate limit for the software. SSD or disk array is very welcome.

NetCrunch is a multi-threaded system that scales well with many processors, especially because many tasks are dispatched to different processes and threads.

Slow SATA disks are very inefficient in reading large quantities of data. We recommend using SSD drives instead.

Diagnostic Report

NCDiag.exe

NCDiag is the program located in the NetCrunch server folder. It allows browsing various logs and bug reports.

Bug Reports

Bug Reports are not crash dumps.

Mostly, they are well-handled exceptions, but something that was not expected by the program.

It is always beneficial when you let us receive them automatically. The reports contain information about your system, memory, processor, and program execution context.

We do not know your computer address except its Windows machine name. All reports come by email, directly to our secure internal database, and are fully confidential.

You can review those files (if there are any) using the NCDiag program located in the NetCrunch server directory.

Logs

As many NetCrunch components run as background processes, they use text logs to store their activity and potential issues. You can review them using NetCrunch Console ApplicationServerLogs.

NetCrunch Logs:

Activity Logs

It contains the list of all actions performed by NetCrunch users.

Atlas Backup

It contains the NetCrunch auto-backup process activity log.

Atlas Import

It contains the import log.

Auto Discovery

Contains activity or issues of the NetCrunch autodiscovery process.

Monitoring Engine

Logs of all NetCrunch Monitoring Engine activity

NetFlow Server

Log of the Flow Collector service.

Report Generator

Log of the process responsible for generating automatic reports.

Server Services

Logs of all NetCrunch Server services activity.

Task Scheduler

The task scheduler is responsible for running the Report Generator and Auto-Discovery process.

Server Status View

You can find this view in the top Atlas view. It contains essential statuses and reports on hundreds of statistics NetCrunch collects on itself.

The report contains information such as memory used, the number of consumed internal resources, and program queues. The report can be exported to file in XML format or sent directly to AdRem Software from the console. It helps us to determine much loaded NetCrunch puts on your system.

NetCrunch Server Emergency Auto Restart

As NetCrunch is the eyes and ears of an administrator, it should work without interruption. In case of an irrecoverable error (blue screen at a smaller scale), NetCrunch service is automatically restarted to bring it back to a healthy state and avoid data loss. This process is done in seconds, not minutes, so its impact on the monitoring process is minimal.