3

I am having problems setting up opengl project. I am following this tutorial. I am able to build it without errors or warnings, but when I execute it I get 0xc000007b error.

It seems my Win32 applicaton tries to load 64bit freeglut.dll in C:\Windows\SysWOW64, because when I deleted it from C:\Windows\SysWOW64 I got error: The program '[3124] Project1.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.

Also in Output I can see:

'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\opengl32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\advapi32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sechost.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sspicli.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptbase.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\gdi32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\user32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\lpk.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\usp10.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\glu32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ddraw.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dciman32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\setupapi.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\oleaut32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ole32.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\devobj.dll'. Symbols loaded.
'Project1.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dwmapi.dll'. Symbols loaded.

What can I do? Thank you

Edit: Pasting 32bit dll directly in visual studio 2012\Projects\Project1\Debug fixes the problem! Why doesnt application look into C:\Windows\System32 folder for library?

rluks
  • 2,762
  • 8
  • 38
  • 56
  • freeglut.dll does *not* belong in an operating system directory. Somebody copied it there inappropriately. And also got the bitness wrong. It isn't clear who that "somebody" is, you might find him between your chair and the keyboard. – Hans Passant Nov 30 '13 at 15:51
  • :-D I was just following tutorial: "Go find the freeGLUT folder you extracted and from the bin folder inside copy freeglut.dll and put it either where your executable will run, or inside of the system directory. C:\WINDOWS\SYSTEM32 is the 32bit windows system directory and C:\Windows\SysWOW64 is the 64bit system directory of 32bit applications. For these tutorials, I'm assuming we're making 32bit applications." Anyway, I put freeglut.dll in Debug folder where executable is, and everything is fine now. – rluks Nov 30 '13 at 15:54
  • Lesson to learn is never to modify the contents of the system directories – David Heffernan Nov 30 '13 at 15:57
  • 1
    Possibly related: [Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows?](http://stackoverflow.com/questions/949959/why-do-64-bit-dlls-go-to-system32-and-32-bit-dlls-to-syswow64-on-64-bit-windows) – Ivan Aksamentov - Drop Nov 30 '13 at 21:02

1 Answers1

4

Things in SysWOW64 are not 64-bit. Those are DLLs used for Windows on Windows (Microsoft's 32-bit translation layer). Basically you have a 64-bit version of Windows, and that is where it stores the 32-bit DLLs.

You actually have it backwards in your head, believe it or not. 64-bit DLLs reside in C:\Windows\System32 on a 64-bit system, as strange as that may sound. Microsoft probably had every intention of using System64 but so much software is/was hardcoded to use System32 and Win32 that the 32 almost has no meaning anymore.

If you want to put your freeglut DLL in a single central location, put it in the working directory Microsoft Visual Studio is configured to run your project from. You can put it in Project1\Debug as you mentioned, but this means you also have to put a copy of freeglut in Project1\Release for your software to function correctly in release builds. Visual Studio actually has a separate working directory in the project configuration ("Debugger | Working Directory") where it will run your program from when you press "Execute" or "Debug" - this is the directory your freeglut DLL should go in to avoid having to put a copy in each build configuration's output directory.

When you ship your software, put it in the same directory as the .exe, but for development take advantage of the projects's working directory. In any case, you should never put a DLL into an Operating System directory unless you know what you are doing. There is a reason you need administrator privileges to write anything to either of the directories you mentioned.

In fact, the author of the tutorial you linked needs to be reprimanded for improperly explaining the function of System32 and SysWOW64 and suggesting you install your DLL to either of those two locations.

Andon M. Coleman
  • 42,359
  • 2
  • 81
  • 106
  • No, current working directory is not what you mean. Same directory as the executable is what you mean. – David Heffernan Nov 30 '13 at 16:28
  • "64-bit DLLs reside in C:\Windows\System32 on a 64-bit system" oh my... Thanks for explanation – rluks Nov 30 '13 at 16:33
  • @DavidHeffernan: Actually, it is what I mean. The DLL search path begins with the path to the executable, if it fails to find the DLL in that directory it then looks in the current working directory. The MSVC debugger tends to use a separate path for executable and working directory at runtime for this very purpose; it makes no sense to deploy your dependency DLLs to each and every build configuration's output directory. – Andon M. Coleman Nov 30 '13 at 16:43
  • It's a security risk in WOR!ing dir. Read the docs. Also it is impossible to control working dir at startup. Your process just takes what it is given. And if it's not what you expect, it's too late. The loader fails to load the DLL. You are giving out very bad advice. – David Heffernan Nov 30 '13 at 16:49
  • @DavidHeffernan: You control the working directory when you run your software through the debugger. I don't see how it is a security risk. My point was not to put the DLL in `\Project1\Debug`, but rather `\Project1` because that is where MSVC most likely defaults the working directory to when you run the software through the debugger. Otherwise, you have to put a copy of the DLL in every single build configuration sub-directory. You might have `DebugProduction`, `DebugDev`, `DebugBeta`, etc. – Andon M. Coleman Nov 30 '13 at 16:51
  • Ah, "most likely". Doesn't sound like a great way to go. You perhaps should make the point that using working directory only makes sense for debugging. Obviously it's a shocker for deployed. – David Heffernan Nov 30 '13 at 16:54
  • @DavidHeffernan: I updated my answer, hopefully my original intention is a little bit clearer now. I was trying to explain how to avoid having to put the DLL in each and every build configuration's `$(OutDir)` without resorting to installing it to a system directory, as-per the OP's comment about pasting to `\Project1\Debug`. – Andon M. Coleman Nov 30 '13 at 17:26
  • Yeah, that's good. There are post build events. Your solution works too. – David Heffernan Nov 30 '13 at 17:48