In unsere Onlinesysteme haben wir einen Mechanismus implementiert, um auftretende Exceptions zu loggen. So finden wir Fehler, die wir mit unseren Tests nicht abdecken konnten oder an die wir nicht gedacht haben.

In meinen Protokollen finde ich nun immer wieder Exceptions vom Typ System.Web.HttpException, die in der Klasse System.Web.Configuration.MachineKeySection und der Methode GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength) geworfen werden.

Der vollständige StackTrace wäre

System.Web.Configuration.MachineKeySection
    GetDecodedData(Byte[] buf, Byte[] modifier, Int32 start, Int32 length, Int32& dataLength)
System.Web.UI.ObjectStateFormatter
    Deserialize(String inputString)

Ich konnte diese Exception nie reproduzieren und recherchierte nach der Ursache.
Ich fand heraus, dass diese Exception geworfen wird, wenn der User einen Request an den Webserver abbricht. Der IIS nimmt den POST-Request entgegen und leitet ihn an ASP.NET weiter, obwohl der Request nicht vollständig angekommen ist.
Ein Beispiel hierfür wäre, wenn der User ein PostBack durch einen Button-Click veranlasst, dann aber bei seinem Browser auf “Abbrechen” drückt oder einfach zur vorherigen Seite wechselt.
In diesem Fall kommt der Request nicht vollständig beim IIS an, die Teildaten werden aber dennoch an ASP.NET weitergereicht.
Klar, dass die Deserialisierung von unvollständigen Daten fehlschlagen muss und so wird die o.g. Exception ausgelöst.

Für uns als Entwickler ist das kein Grund zur Beunruhigung, der User bekommt von der Exception nichts mit, wir können sie also getrost ignorieren.