Fixing Win32 Unhandled Exception in Silverlight Web App

Today while testing we encountered a strange scenario in our Silverlight Web App. We were getting a System Win 32 error when running the deployed application. unfortunately the error was not reproducible when running the app in debug (F5) mode.
Here is a snapshot of the exception message.

When starting a new instance of Visual Studio to debug this JIT issue all we got was that there was a Stack Overflow causing this issue. But that's all; no source code or stack trace to pinpoint the exact code that was causing the trouble. Duh!!


How often do you get in a scenario where you can see a bug in deployed or published code but not in debug mode giving you no option to pinpoint the exact code causing the trouble? Believe me, it happens to me all the time.
And, my best tool to fight this situation is TaDa! Trial & Error :D

How? I pop-in many Message Boxes in the methods that I feel could be erroneous & keep deleting them when I am sure that the method is not the one I am looking for.
Returnng to the issue today, I have a record in my Silverlight Grid, which when double-clicked should open a child window having the details & this part of the code was the culprit. Feels great to zero-in & find the guilty.
So the problem is in the child window looking forward tells me it's a TextBox that has the ValidatesOnDataErrors property set to true.
Here was how it was layed out on the screen:

<TextBox Text="{Binding ProfileName,ElementName=RadWinEditMenuProfile, Mode=TwoWay, NotifyOnValidationError=True, ValidatesOnExceptions=True,ValidatesOnDataErrors=True, TargetNullValue=''}"

 x:Name="txtBoxProfile" MaxLength="50" />

Notice the  ValidatesOnDataErrors=True property.

So next step was to remove it & Voila! It worked. No error this time.
But wait, we have that property set for a reason. We want to force the TextBox to show an error on all data validation errors. Having that figured out I knew the next thing we need to look into was the code that was doing the data validation.
Here is the code used for it:

Public ReadOnly Property [Error] As String Implements System.ComponentModel.IDataErrorInfo.Error


        Return _Errors

    End Get

End Property


Default Public ReadOnly Property Item(propertyName As String) As String Implements System.ComponentModel.IDataErrorInfo.Item


        Select Case propertyName

            Case "ProfileName"

                If String.IsNullOrWhiteSpace(ProfileName) = False Then

                    'ProfileName = ProfileName.Trim

                    If context.MenuProfiles.Any(Function(t) t.Id <> SelectedProfile.Id AndAlso t.ProfileName.ToLower.Trim = ProfileName.ToLower.Trim) Then

                        _Errors = _ErrorsText

                        Return "Profile Name is already in use."

                    ElseIf Regex.IsMatch(ProfileName.ToLower.Trim, CustomDeclaration.REG_NAME) = False Then

                        _Errors = _ErrorsText

                        Return CustomDeclaration.INVALID_NAME

                    End If

                End If

                Exit Select

        End Select

        Return Nothing

    End Get

End Property


Private _ProfileName As String

Public Property ProfileName() As String


        Return SelectedProfile.ProfileName

    End Get

    Set(ByVal value As String)

        _ProfileName = value

        SelectedProfile.ProfileName = value


    End Set

End Property
This is a standard implementation of IDataErrorInfo, so I will not get into the gory details of it and go directly to the code that was the issue.
Note that I have commented-out the line:

'ProfileName = ProfileName.Trim
This was the exact line of code causing the issue. I was trimming the property & then assigning it back, that in turn was calling the setter of the property & that in turn was calling the validation again.
Evidently, these two caused an infinite loop L L Not a good deal.

This was the reason why we were getting the Stack Overflow error.
Commenting out that line & using trim wherever we were actually using the property.

For example:

Changed ProfileName.ToLower to ProfileName.ToLower.Trim fixed the issue once & for all. Nice & Cool.
So the next time you hit a stack overflow in your published code try to pin point the code & check if you are not implementing IDataErrorInfo or any other 2 properties that are dependent on each other like I was implementing it.
Hope this article saves some time to someone out there.

Similar Articles