none
C#/WPF - Platform target at Any CPU or x64 locks files

    Question

  • I noticed that when you set the Platform target in Visual Studio to Any CPU / x64 some files are getting locked (e.g. aticfx64.dll, which is a device driver file for AMD display). However, with the Platform target on x86 no files are locked.

    We need the Platform target at Any CPU, but we don't want these files locked. I already went on the internet, but couldn't find anything about this issue. Does anyone have a suggestion on how to fix this or came across a similar problem? Thank you ;)

    Thursday, May 03, 2012 4:05 PM

Answers

  • Just the fact that the DLLs are not used when they are not installed is not sufficient for claim they are not needed (think DelayLoading). Maybe they contain some extra features that WPF engine uses and scans for (e.g. implementation of some driver specific APIs). Their installation probably registers the DLLs at the 'right' place for something in WPF app to pick them app and load them.

    If you want to know who is loading them for sure and why, your best chance is to debug it (e.g. it may be antivirus). My guess is that the answer from the owners of the code will be anyway "This is by design", no matter if it is WPF engine, 3rd party DLL or antivirus.

    -Karel

    Thursday, May 24, 2012 4:12 PM

All replies

  • Hi Marcel,

    Welcome to the MSDN forum.

    We’re doing research on this issue. It might take some time before we get back to you.


    Bob Shen [MSFT]
    MSDN Community Support | Feedback to us

    Friday, May 04, 2012 9:05 AM
  • Hello Bob,

    Thank you for your reaction. I've investigated a bit further, and I found out that the following files are somehow injected:

    C:\Windows\System32\aticfx64.dll

    C:\Windows\System32\atiumd64.dll

    C:\Windows\System32\atiumd6a.dll

    C:\Windows\System32\atiu9p64.dll

    I tried to remove these from the process using FreeLibrary (as they are not .NET dlls), but only aticfx64.dll was possible to free, the rest resulted in an instant crash.

    Looking forward to hear back from you with updates regarding this issue.

    Friday, May 04, 2012 9:20 AM
  • Hi Marcel,

    Can you tell us what kind of application are you developing please?


    Bob Shen [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, May 09, 2012 4:46 AM
  • Hello Bob,

    It's a WPF application with .NET 4.0 Client Profile. This application is trying to fix some problems with AMD display drivers, requiring one of these files to be moved, but as these are somehow injected into my .NET application, I'm unable to. I can ofcourse move these files with MoveFileEx, but that's a workaround requiring a reboot, which I'm not willing to make if not needed. I just want these dll's not to be injected into my .NET application.

    Wednesday, May 09, 2012 8:47 AM
  • Hi Marcel,

    I’m afraid that it is not the correct forum about this issue, since this forum is to discuss Visual C#. I am moving your question to the moderator forum ("Where is the forum for..?"). The owner of the forum will direct you to a right forum. Thanks for your understanding.


    Bob Shen [MSFT]
    MSDN Community Support | Feedback to us

    Wednesday, May 09, 2012 8:52 AM
  • Hello Bob,

    Alright, but did you find anything out regarding this issue?

    Wednesday, May 09, 2012 8:54 AM
  • Unfortunately no one here will know the direct answer. This was moved to the Where Is forum.

    Try asking here...

    http://social.msdn.microsoft.com/Forums/en-US/wpf/threads

    Or pick a forum here: http://social.msdn.microsoft.com/Forums/en-US/category/netdevelopment

    Thanks!


    Ed Price (a.k.a User Ed), SQL Server Experience Program Manager (Blog, Twitter, Wiki)

    Thursday, May 10, 2012 2:07 AM
  • I think this forum has the most chance for a solution:

    http://social.msdn.microsoft.com/Forums/en-US/clr/threads

    Can you move it?

    Thursday, May 10, 2012 7:10 AM
  • Are those files used also at your application run or only during VS run?

    Can you reproduce the problem on more than 1 machine?

    Can you reproduce the problem on clean OS + VS install? (no plugins, extra SW or anything else)

    -Karel

    Tuesday, May 22, 2012 6:32 AM
  • Hello Karel,

    1) Yes, they are locked both at normal run (release build) and during VS debug.

    2) Yes, the same problem occurs on my laptop (which also has AMD display drivers installed).

    3) Depends on the definition of a clean OS install, in case no AMD display drivers are installed this isn't the case (ofcourse ;)). Also, even without VS installed this problem occurs when AMD display drivers are installed. Probably there are several other dll files locked, but as I don't require these files to be moved they are no use to me. I still want to prevent these files from being injected into my process and thus being locked.


    • Edited by Marcel-NL Tuesday, May 22, 2012 7:29 AM
    Tuesday, May 22, 2012 7:28 AM
  • Hi Marcel,

    atiumd64.dll - is a Dynamic Link Library (DLL) file used for the systems like Windows 7, Windows XP and Windows Vista.

    atiu9p64.dll - This files belongs to product Advanced Micro Devices, Inc PowerXpress Vista User Mode, etc 

    atiumd6a - for video accelaration driver.

    There are utilities available on net. You can repair them.

    Please try to repair mentioned files and then check, if issue still persist.


    Regards, http://shwetamannjain.blogspot.com or https://shwetalodha.wordpress.com/

    Tuesday, May 22, 2012 9:21 AM
  • Hello Shweta,

    I know what the files do and are, that is not the issue here. Also updating to a newer driver version doesn't help, files are still injected into my executable. I do not want this, so my question remains, how to prevent these dlls from being injected?

    Tuesday, May 22, 2012 9:25 AM
  • I think you will have to track down which code locks the files. Run your app under debugger, and check if the files are being loaded. Another option is to use ProcMon and check out the callstack (make sure you have the right symbols, not just export symbols).

    Also note that it is possible that they are locked by OS or WPF by design for proper functioning.

    -Karel

    Thursday, May 24, 2012 3:23 AM
  • There is no own code causing this, creating a new WPF application has the same issue. It's just that as soon as any application is executed that these dlls are loaded. There should be no reason to lock these files for proper functioning, because when you remove the drivers (and thus the files aren't on the OS anymore) these dlls are also not loaded anymore, while everthing is still working fine.

    When you take a look with Process Explorer you can see the DLL there, the problem is not that I don't know or can't see that it's injected, the problem is that I want to prevent that :)

    Thursday, May 24, 2012 6:53 AM
  • Just the fact that the DLLs are not used when they are not installed is not sufficient for claim they are not needed (think DelayLoading). Maybe they contain some extra features that WPF engine uses and scans for (e.g. implementation of some driver specific APIs). Their installation probably registers the DLLs at the 'right' place for something in WPF app to pick them app and load them.

    If you want to know who is loading them for sure and why, your best chance is to debug it (e.g. it may be antivirus). My guess is that the answer from the owners of the code will be anyway "This is by design", no matter if it is WPF engine, 3rd party DLL or antivirus.

    -Karel

    Thursday, May 24, 2012 4:12 PM