views:

70

answers:

3

I have a WPF application that runs fine on my Vista development machine, but not on the production XP boxes. The only problem is with a call to OpenFileDialog.Show(). As soon as I call the method, the application is terminated on the XP box.

The problem does not trigger an exception. (I've surrounded the block in a try-catch block to no avail.) When I click on File->Open the application just up and quits in XP. Interestingly, I can write files to disk with File->Save and using the Save As dialog. I've tried building it to .Net 3.0 and 3.5 but it doesn't make a difference.

I've tried both Microsoft.Win32.OpenFileDialog and System.Windows.Forms.OpenFileDialog and get the exact same symptom.

The code block for the Microsoft.Win32 variant:

try  
{  
    OpenFileDialog ofd = new OpenFileDialog();
    if (ofd.ShowDialog().Value)
    {
        //do something
    }
}
catch (Exception ex)
{
    MessageBox.Show(ex.ToString(), "Error!");
}

The only clues I have is the following (partial) entry from the security event log.

Event Type:     Failure Audit
Event Source:   Security
Event Category: Object Access
Event ID:       560
Description:
Object Open:
        Object Server:  Security
        Object Type:    Key
        Object Name:    \REGISTRY\MACHINE\SOFTWARE\Microsoft\EnterpriseCertificates\Disallowed
        Accesses:       DELETE
                        READ_CONTROL
                        WRITE_DAC
                        WRITE_OWNER
                        Query key value
                        Set key value
                        Create sub-key
                        Enumerate sub-keys
                        Notify about changes to keys
                        Create link

Any ideas? (Pleeeease!)

A: 

It seems there is a permission problem with the registry key. My first suggestion would be to check the permissions on that key and verify that the ACL's are correct (best compare them to another XP box where the app is working).

If the permissions are OK, then you should try reinstalling .NET (maybe the installer will reset some required permissons on the registry keys).

If all else fails, reinstall XP on problematic machines, unless someone has a better idea.

Marko
A: 

It doesn't appear your production assembly is running under full trust. Are you running from a network share?

David Crowell
A: 

Thanks for the advice. I verified both the registry permissions and the full-trust issue. It turns out that, although I specifically built my application to .Net 3.0 (based on the standard organizational image), there was a dependency on .Net 3.5 SP1 that I still don't fully understand. The solution to my problem was to install .Net 3.5 SP1 on all the affected computers.

I just wanted to close the loop. Thanks, again, to all who contributed ideas.