Attempted to read or write protected memory in a Windows Forms app

Question

As a preface, I've looked at every StackOverflow question matched by searching for this error (25 of them or so), and none of them seemed to address the problem I'm having.

I'm building up a PermissionsDialog that inherits from System.Windows.Form. Within the method that calls dialogPermissions.ShowDialog() I am retrieving some Role objects from the database and loading them into a couple of ListBoxes. That was working just fine, but now I need to override one of the properties of the Role objects I'm adding to the listboxes using this pseudocode process:

• iterate over the List of Roles
• look up a matching item out of a List of Profiles using List<T>.Find()
• look up a property on the Profile
• build up a new Role and set the Name property as needed
• add the Role to a list of Roles for the PermissionsDialog

All of that goes smoothly, but when I call dialogPermissions.ShowDialog() the underlying framework code throws an AccessViolationException.

Here is what I believe to be the relevant code:

List<UserProfile> userProfiles = new List<UserProfile>();
List<Role> allRoles = new List<Role>();
dialogData.AllRoles = new List<Role>();

using (var objectContext = this.SiteContext.CreateObjectContext())
{
    userProfiles = rs.UserProfiles.FindAll().ToList();
    allRoles = rs.Roles.FindAll();
}

foreach (Role role in allRoles.Where(role => role.BuiltInId == (int)BuiltInRoleId.UserProfileRole)) {
    var userProfile = userProfiles.Find(up => role.Id == up.Id);

    var roleToAdd = new Role {
        BuiltInId = role.BuiltInId,
        Description = role.Description,
        DirectoryEntry = role.DirectoryEntry,
        Id = role.Id,
        IsBuiltInRole = role.IsBuiltInRole,
        Name = null != profile ? profile.DisplayName:role.Name
    };
    dialogData.AllRoles.Add(roleToAdd);
}

My suspicion is that this is somehow a deferred execution issue, but triggering execution by calling ToList() on dialogData.AllRoles before calling ShowDialog() doesn't resolve the issue. When I replace profile.DisplayName with a constant string I do not get the error.

Any clues what's going on under the covers here, or how to find out what's going on, or how to approach the problem differently so I can avoid it? All suggestions welcome ;-)

CONCLUSION

So here's the actual issue, I think:

Setting the Name property of the Role to null is just fine, but when the dialog tries to create a ListBoxItem out of the Role and uses the Role.Name property for the ListBoxItem's Content property (which is an Object), that can't be set as null and throws down in the framework code that's building up the dialog. Checking to make sure I had a value in there fixes the issue.

Seems like s strange exception to throw, but there you have it....

Answer 1

You test for profile != null, but don't test for profile.DisplayName != null so that's the first thing that comes to mind from just looking at your sample.

Standard exception finder is to go to Debug\Exceptions and check the box for break on thrown so you can see all the state when the exception is thrown.

Answer 2

You can stare at this code for a week and never find the reason for the AccessViolationException. Managed code does not die from processor faults like this one.

You'll need to dig out as much info you can get from the actual exception. That requires first of all that you enable unmanaged code debugging so that you can see the stack frames in the native code. Project + Properties, Debug tab, tick the "Enabled unmanaged code debugging" option.

Next, you want to make sure that you have .pdb file for any of the native Windows DLLs. Including the ones for Active Directory, somewhat suspect in this case. Tools + Options, Debugging, Symbols and enable the Microsoft Symbol Server. Press F1 if you have an older version of Visual Studio that doesn't make it a simple checkbox click.

Reproduce the crash, the call stack should give you a good hint what native code is suspect. Post it in your question if you can't make hay of it.