7

We have a particular Vista x64 machine that, when running our C# WinForms app, displays the following error:

System.EntryPointNotFoundException: Unable to find an entry point named 'TaskDialogIndirect' in DLL 'ComCtl32'.

This same code works fine on other Vista machines. For some reason, this particular Vista machine always throws this exception.

How can we fix this?

Judah Gabriel Himango
  • 58,906
  • 38
  • 158
  • 212

4 Answers4

10

I had problems with this and Naughter's free XTaskDialog API, to get a fallback mechanism on Windows XP machines via emulation, rendering this dialog implementation much more useful. :)

In my case it was an activation context issue, as mentioned in this blog entry.

Or, quoted here, in case the blog post is lost in cyberspace some day (applies to Visual Studio):

  1. Open your project properties in the Solution Explorer,
  2. On the Security tab, check Enable ClickOnce Security Settings,
  3. Now you can see appearing the app.manifest file in the Properties folder of your solution, open it,
  4. Beneath the </trustInfo> tag, insert the code below.
  5. If you try to build, there may be an error. To fix it, uncheck the Enable ClickOnce Security Settings.

The code to insert in step 4:

<dependency>
  <dependentAssembly>
    <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" 
        version="6.0.0.0" processorArchitecture="*"
        publicKeyToken="6595b64144ccf1df" language="*" />
  </dependentAssembly>
</dependency>
Judah Gabriel Himango
  • 58,906
  • 38
  • 158
  • 212
Jonas
  • 1,172
  • 1
  • 16
  • 26
  • I'm having the same issue in a dll library project (Excel plugin). There's no security tab in VS studio for library projects? – Niels Bosma Jan 22 '12 at 09:20
  • 1
    Currently (VS 2012/2013) this solution doesn't work :( This however works like a charm: http://support.microsoft.com/kb/830033 – Sverrir Sigmundarson Oct 01 '14 at 13:37
  • Know this is an old thread, but thought I'd add that you can now just add an app.manifest file by using the Project > Add file command. @jonas - thanks, your answer helped me almost 10 years later. ;) – Dax Pandhi Jan 26 '18 at 08:53
1

Had this problem today with a ClickOnce application.

The only thing that worked was this solution: http://support.microsoft.com/kb/830033

Internet archive as the original link has gone dark https://web.archive.org/web/20110313122806/http://support.microsoft.com/kb/830033

Sverrir Sigmundarson
  • 2,453
  • 31
  • 27
1

I would suggest comparing the version of comctl32.dll on the working and non-working Vista machines -- and comparing their checksums even if they report the same version.

Other things to check:

  • Is it possible that the non-working machine has a pre-release version of Vista?
  • Is it possible that a non-Vista version of comctl32.dll has been copied onto the machine and is being picked up by the application? (The Depends utility that comes with Visual Studio may help here.)
  • Is it possible that a virus or worm (or what not) has replaced the comctl32.dll?

It might also be worth reading this article on activation contexts.

Paul Ruane
  • 37,459
  • 12
  • 63
  • 82
1

If the other machines you used to run the program were using Vista x86 it's likely that there's a PInvoke in your code that's causing the issue. You may want to try setting the compiler target architecture to x86 to force your program to run in WoW64 on the x64 Vista. By default, Visual Studio uses settings building assemblies in architecture-agnostic ways. That means that when you try to run a .NET program on a 64bit system it should be run hosted by a native x64 version of the CLR. Attemptiong to load a 32bit DLL in that context will fail. Forcing the app to run in emulated x86 mode, instead, should do the trick.

em70
  • 6,088
  • 6
  • 48
  • 80