I definitely think we need to keep the exceptions abstracted into a new table to allow us to use the data for the original intent. This way, folks like us can do better analysis of what is affecting a DNN instance. We just need to fix the data and have a UI for it.

Yeah, it looks like that FIPS-compliant issue was the cause of the issue I was seeing. (Some government computers have a FIPS-compliant setting which causes programs to crash when they try to use the MD5 function or other non-compliant algorithms, so even though it’s not being used in a security context, it’s important not to use it).

I found this out when I used this code as the basis for a function I was using and realized it didn’t work. Here’s what I ended up with:

using (var hasher = SHA1.Create())
{
    var byteArray = hasher.ComputeHash(Encoding.Unicode.GetBytes(data));
    var hashedToken = Convert.ToBase64String(byteArray);
    return hashedToken;
}

Personally, I don’t know that I’ve ever used the data in the table to look at exceptions in the aggregate, but if there were a view of aggregate exceptions, I would think it was useful.

I wouldn’t offload the XML blurb to disk, that would make analysis unnecessarily more difficult.

There is a lot of “junk” in there as well which looks more like something for a regular (disk based) log. I’d keep the best bits in SQL.

@daguiler I think it’s actually an issue that the function being used to calculate the hash doesn’t use a stable key/salt, so the same content will generate different hashes. I discovered this recently, but haven’t had a chance to verify and submit an issue.

Assuming that’s true, it would certainly seem like no one has found this data useful since it started being collected (other than, perhaps, granting some false assurance against consistent exceptions). On the other hand, if we fix this issue and expose some more exception details in the UI, perhaps it would end up being good information to have.