Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials

SNMP Trap Services broken after update to 10.1

Hi,

I've already opened a support case on this but I wanted to see if anyone had experienced the same issue. I just upgraded my servers from 10.0.X to 10.1.1. Now the trap service on all of them crashes. I have one main Orion server and two polling engines all running Windows 2008 R2 server. This is what I get in the windows event log:

Fault bucket , type 0

Event Name: CLR20r3

Response: Not available

Cab Id: 0

Problem signature:

P1: swtrapservice.exe

P2: 2010.2.1.0

P3: 4cfd0d06

P4: SWTrapService

P5: 2010.2.1.0

P6: 4cfd0d06

P7: 75

P8: ec

P9: System.ArgumentException

P10:

Attached files:

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_swtrapservice.ex_f3ef6deb80438f3061404174604d2b307d25a781_2b962440

Analysis symbol:

Rechecking for solution: 0

Report Id: 6fa4e6ab-0ea7-11e0-b967-005056a10001

Report Status: 4

Is there some other windows features that need to be enabled to make this work?

Find more posts tagged with

Accepted answers

smargh

I currently have case ref 208394 open since last Friday (17 Dec) for this problem.

Orion is hosted on a decent 2008 R2 box. The problem did not exist on 10.0 SP1, but does on 10.1.1 with both hotfixes, but it's a bit awkward to say specifically that 10.1.1 is at fault because we only started sending a large number of Windows traps to Orion after we upgraded to 10.1.1.

My initial diagnostics indicated a possibility that it might be caused by the IPv6 records of the servers which are sending traps to Orion. Support seems to be a bit stumped though.

I haven't yet done the 0xffffff registry thing to disable IPv6 on the OS of the Orion engine, as I want support to fix this for other people too, not just me.

All comments

MarieB

Hi yogi-

If you don't get an answer from the community, would you please post your answer from support here?

Thanks,

smargh

I currently have case ref 208394 open since last Friday (17 Dec) for this problem.

My initial diagnostics indicated a possibility that it might be caused by the IPv6 records of the servers which are sending traps to Orion. Support seems to be a bit stumped though.

I haven't yet done the 0xffffff registry thing to disable IPv6 on the OS of the Orion engine, as I want support to fix this for other people too, not just me.

profzoom1

Same issue as well with my brand new install of NCM 10.1.1 sp1 on a freshly built Win 2008 r2 box with the database hosted on a different server getting the same error it looks.

I have not opened a ticket yet was waiting to see if there was a fix here first.

Fault bucket , type 0

Event Name: CLR20r3

Response: Not available

Cab Id: 0

Problem signature:

P1: swtrapservice.exe

P2: 2010.2.1.0

P3: 4cfd0d06

P4: SWTrapService

P5: 2010.2.1.0

P6: 4cfd0d06

P7: 75

P8: ec

P9: System.ArgumentException

P10:

Attached files:

These files may be available here:

C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_swtrapservice.ex_f3ef6deb80438f3061404174604d2b307d25a781_578b9fbd

Analysis symbol:

Rechecking for solution: 0

Report Id: 5d5ff621-24b2-11e0-bc87-1cc1de6ce53c

Report Status: 4

smargh

Same issue as well with my brand new install of NCM 10.1.1 sp1 on a freshly built Win 2008 r2 box with the database hosted on a different server getting the same error it looks.
I have not opened a ticket yet was waiting to see if there was a fix here first.

My problem with the trap service crashing was resolved by making my Windows servers send the traps to the IP of the Orion engine, rather than the hostname. There are two entries in DNS for my Orion server - IPv4 and IPv6. Sometimes the trap was sent as IPv6, causing the crash. Specifying the v4 IP as the destination has resulted in the trap service not crashing since.

Support informed me that this problem should be fixed in the version after next.

You may be able to use logic to decide whether this problem is applicable to your network - in my case, the problem only happened when servers in the same physical building sent traps, because IPv6 traffic probably would never reach the main datacenter as we have no need to set up IPv6 routing. Alternatively, just set Wireshark going and capture only IPv6 packets, then correlate those with the times when the service crashes.

profzoom1

Mine are all set to go to an IP address but still erroring out. Is there a place in Orion to specify the trap server, I have not found it.