Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CSPM database issue

I ran the cvtnrlog utility with the -d option to clean out the database of two months worth of alarms. The cvtnrlog utility ran for a full 24 hours. Once it was completed I was unable to enter the database event viewer now. I get the following error messages:

newDbEventCallback, error caught in catch block.


newDbEventCallback, eventStreamConsumer -> Read Failed.

I tried rerunning the cvtnrlog utility to see if the database is actually collecting alarms and received a wonderful Dr. Watson error with the following detail:

Exception: access violation (0xC0000005), Address: 0x10201695

Any ideas?

Jason Fletcher

  • Other Security Subjects
Cisco Employee

Re: CSPM database issue

I did a quick bug scratch for the Dr. Watson error you got, and found the following bug CSCdv37259



New Member

Re: CSPM database issue


Unfortunately, it appears that you have corruption in your database. There are two options that you should consider at this point. In both cases, you must have a copy of your Topology (.cpm file) to recover your configuration. If you do not, you will have to add your sensor(s) back in.

The first option is to us the 'Troubleshooting Toolkit'. Close CSPM and go to "Start>Programs>Cisco Secure Policy Manager>Troubleshooting Toolkit". Go to the Restore policy database tab. Select Restore to orginal and then hit the Restore button. This may take a few minutes, and as the process is completed, you will see check marks fill in the boxes. Once this is complete, close the toolkit and reboot the server. (not require, but a good idea).

Bring CSPM back up and select File>Import from file. Point this at your .cpm file. Then do a File>Save and Update.

If this does not work, then as a last resort, you must reinstall. There is no other way to repair corruption, than the two methods above.

If sounds like you had quite a few alarms in your database, if it ran for 24 hours. I would suggest that you run this more frequently. Don't let the database get above 59k alarms in it if possible. This value is not documented, just a suggestion based on my experience. There are other factors that influence the number of alarms that can be in the database, but this is a pretty good rule of thumb.

One of the above methods should resolve your issue, but if for some reason it does not, or you have further questions, the don't hesitate to contact the TAC for assistance.



New Member

Re: CSPM database issue

I also experienced database corruption on or about the 2 month period. After speaking with the DE, the work-around that I use today is to only perform maintenance with the default administrator profile that was used to install. This has allowed me to keep the database for 6 months(and still going). The installation has many registry keys that tie to the profile that installed the program. I was unable to gather from TAC the effects of editing the registry, and requirements to keep this database for trending purposes has binded me to use the administrator profile.

New Member

Re: CSPM database issue

Hi Jason,

Do you have an export of the configuration .CPM file? If so, open the Troubleshooting Toolkit from the CSPM Program Menu and find the appropriate tab to restore the database to the original form. This will also wipe away your config, hence, the need to the export prior to the restore. You will also have to take CSPM back to the correct signature and version level.

CSPM does have issues with database size, so I would recommend backing up the database on a regular basis and then restoring to original to start fresh. If you need the data, you can always restore from a backup.


Re: CSPM database issue

Jason, I run v2.3.3i on NT4 SP6a (IE 5.5) and have always experienced what I consider to be a significant problem with the "cvtnrlog function"...that is, its inability to convert the database to log format "cvtnrlog" successfully even after what I consider to be relatively few events. For instance, even after a week the ability to cut a log file stopped and I only have 2 sensors. I've used the support tool but have found it easier to reinstall from scratch after exporting the topology, etc. I've opened a TAC case on this to no avail. I don't get the same error you do but the effect is the same. Unfortunately, I don't trust this functionality of the system and even more unfortunately, that means I convert the DB to log format every 3 days! Worse yet, there isn't an obvious way I've found to combine all the log files for history analysis/correlation. I've had no problem with opening a database of 20MB which represented about 3-4 months worth of events...just a problem cleaning out/archiving the DB (cvtnrlog) after an indeterminate amount of time...consequently, I clean out DB before it gets very big. Basically, I'm cleaning out about 1000-1500 events every 3 days resulting in a logfile of about 220k.

Stan Prothero, CCNA, CCDA, MCSE