Parsing Application Log fails

[RSAAdmin]

Once again, I find messages in the event logs of my servers that I am unable to run a report on. I've spent the last hour running through queries on just about every table listed. My search comes up dry. The event is in the Application log. The raw message shows up, but when I try to run a report or query, I can't find it in any table. What am I missing?

Event Type: Warning

Event Source: ASP.NET 2.0.50727.0

Event Category: Web Event

Event ID: 1309

Date: 2/18/2011

Time: 5:19:41 PM

User: N/A

Computer: VMSER2-2WEB01

Description:

Event code: 3001

Event message: The request has been aborted.

Event time: 2/18/2011 5:19:41 PM

Event time (UTC): 2/18/2011 11:19:41 PM

Event ID: 435043f3b20040aba02aab4411e80bd4

Event sequence: 31964

Event occurrence: 12

Event detail code: 0

Application information:

Application domain: /LM/W3svc/1/Root/rmis-1-129424973169485000

Trust level: Full

Application Virtual Path: /rmis

Application Path: C:\Program Files\Application\applicatin_name\Site\

Machine name: VMSER2-2WEB01

[RSAAdmin]

I think that it might be that it is an unknown/undefined message.  An unknown/undefined message will show up in Event Viewer, but would not be parsed into the table. 

The way to check would be to take the event and run it through the UDS tool and see if it parses it...if it doesn't it is an unknown message.  You could also use ESI and parse it through and see if it is defined.

If you aren't comfortable with ESI or UDS, attach the event from an lsdata and one of us in the community could probably help you out.

If it is unknown, then it would either need to be defined in the Windows device XML or a new device XML would have to be created for the application.

[RSAAdmin]

I've already looked in the Windows XML. There is no Application_1309_X event.

So as Paul said, you will be able to view the raw log in the EventViewer, but it will not parse anywhere for reporting purposes.

[RSAAdmin]

I had checked and didn't see it either...but I trust and verfiy   So, I usually do try to run it through UDS or ESI as a double check. 

[RSAAdmin]

Thanks everyone. I did what I thought was correct but still no luck. I did not add as a new device but rather edited the header. It passed all the tests after running the ESI wizard but still no luck seeing this in the reports. I am obviously missing something. See the attached file and note Header 0008. Do I have to edit a specific header or all headers for this to work? Please advise..

Thanks,
Chris

[RSAAdmin]

I got this to work with some help from support. However, it did spawn some questions. We ended up using the Windows Level table. I'm not sure why and there are limited variable options there. The application is running on a Windows server. What determines which table to use for an "unknkown" event being reported in Windows event viewer in the application log? I will be taking the ESI class but not till April) : )

[RSAAdmin]

The choice of table that is used is ultimately an arbitrary decision made by the XML developer (in other words, the person doing the UDS/ESI).

That said, there are some choices that can be made to intelligently assign messages to logical places that you will learn about in class.

If you are using Content 2.0 (you decide this when you do the monthly Event Source Updates), your table choices ultimately become even easier as the tables are being consolidated. 

Example:

In content 1.0, for windows events, you have to contend with Windows Accounting or Windows Level

In content 2.0, this has all been consolidated into a single Windows table.

[RSAAdmin]

Well there are the headers and then there are the messages. So, the header may match but did you write the message XML to parse the message?

[RSAAdmin]

Thanks Matt. That will help when we go to content 2. Last question. I had to start over since my header was too restrictive.

The header allows you to define a few variables and leave the rest as static.

I went through the process and defined many more variables for the message but there was no “default the rest to static” so I am guessing I’ll have to go back and define everything that is not a variable as static or payload. Is that correct? You cannot leave any part of the message not assigned to something?

Since I didn't do that, I have to start over. Is there any way to pick up where I left off instead of starting from scratch?

Thanks again,

Chris

[RSAAdmin]

Anything that is static (or "fixed text" as I like to call it) needs to be defined as-is in your content parameter.

For example:  if your log message looked like this:

User Matt login into 1.2.3.4 successful

where the variables are highlighted in red, and the static/fixed text is in blue

then your content parameter might look like this:

content = "User <usename> login to <daddr> <status>"

You simply enter the non-variable components as they exist in the raw log.