Security Incompatability between .NET Framework 3.5 and 4.0? RRS feed

  • Question

  • Hello,

    I ran into an interesting issue when running a piece of code under .NET Framework 3.5 vs .NET Framework 4.0 RC.

    I have a Project called Win32Interop (which I use for my Win32 API calls), that is built with Target Framework: .NET Framework 3.5

    I have a seperate Project (seperate solution) called: Test35.  This is built with Target Framework: .NET Framework 3.5

    In Test35, I add a reference to the DLL built from Win32Interop project, add one line of code to call an API in that DLL, then execute this Test35 project.

    It works perfectly fine, and returns a valid result. 

    However, when I change the Target Framework of the Test35 project to: .NET Framework 4.0, and re-run the same project (no code changes anywhere, no other configuration or XML changes anywhere), the code executes, but does NOT return the correct result. 

    I've verified, going back and forth, numerous times, and the behaviour is always predictable: When built with .NET Framework 3.5, I get the correct result from the Win32Interop call, but when executing with .NET Framework 4.0, I do not.

    To me, this suggests there may be a backwards incompatability between .NET Framework 3.5 or 4.0 (unknown if by design or not).

    The reason I suspect it may be security related, is due to the underlying call in the Win32Interop library that is being executed:

                IntPtr cFile = Win32FileApis.CreateFile(

    This is a Win32 API to get a handle to a file, while using the FILE_FLAG_BACKUP_SEMANTICS flag (which is directly related to bypassing/ignoring security settings on a file).

    Now, this is where it gets interesting:
    When the Test35 project is built with .NET Framework 3.5, everything works fine (I can access files that NEED that flag, and those that do not).
    When the Test35 project is built with .NET Framework 4.0, it does NOT work fine (I can *NOT* access the files that NEED that flag, *HOWEVER* I *CAN* access the files that do not!).

    This means that the underlying call to Win32's CreateFile is 'kind of' working, in the sense that the Handle is being marshalled back and forth correctly, and the call is succeeding.

    If I had to guess, it would look like there is something about the .NET Framework 4.0 CLR that is preventing me from running with those 'elevated' privileges.  Please keep in mind that I am running both versions of the code (3.5 and 4.0) from the exact same IDE, on the exact same machine, as the exact same user, and targetting the exact same file, without doing any rebooting/logging off or even restarting Visual Studio.  As far as I can tell, the *ONLY* change is the .NET Framework being used (3.5 or 4.0).

    I'm *HOPING* that a new feature was added to the .NET Framework 4.0 that restricts security of this type, and that it can be 'solved' by adding some decorations to my objects (or an extra API call).

    If anyone can offer any assistance on this, or needs more information, please let me know.

    Thank you.

    Friday, March 5, 2010 10:05 AM


  • It might be issue in your PInvoke signature. Can you post it here?
    Can you please create minimal repro which has only this PInvoke and calls only this API and post it here? (So we can easily try it)

    There have been changes around PInvokes in Dev10. If your PInvoke marshalling info is incorrect it might work in 3.5 only by chance and can stop working in 4.0. Or there might be other things affecting this. It is definitely worth looking at.

    Friday, March 5, 2010 6:12 PM