I'm in the process of debugging my application, which was working well with opengl on Windows 10. The app is broken because of a seemingly missing opengl function. The problem seems to have started when I installed the latest update for Windows 10. I suspect that opengl32.dll is missing key functions for Windows.
Specifically, I always gained access to wglChoosePixelFormatARB by calling Windows wglGetProcAddress. However, wglGetProcAddress now returns a null pointer for this function.
As a workaround, I tried to gain access to wglChoosePixelFormatARB by using the LoadLibrary of opengl32.dll and GetProcAddress. The return value is still a null, and the GetLastError returns ERROR_PROC_NOT_FOUND.
To double-check the issue, I downloaded a dll export viewer tool from nirsoft.com. I saw that wglChoosePixelFormatARB is not listed in opengl32.dll, whereas the older function, wglChoosePixelFormat, is there. The wglChoosePixelFormat function is a much older way to choose the format. What is the logic behind distributing this opengl32 dll?
I read the following answer from Microsoft, but it doesn't seem that another update is available or that the answer will fix my problem:
https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/problems-with-opengl32dll/23c4b0e6-8742-412a-8a4e-2c6024cc78e1
Does anybody have a suggestion?
Turns out that Dell's Intel HD driver update from Nov 2017 is messing up OpenGL. One way to solve the problem is to use Dell's older driver update.
This might be wrong; the older drive might not include the Intel security update. Choose your poison.
The working driver is here:
https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverId=40Y1J
Related
My application relies on DBGHELP.DLL functions, especially the information about the loaded DLLs by the target processes. However, many times it fails on Windows versions lower to Vista (you know XP is still there!). Looked around and found that installed/present DBGHELP.DLL on the target system is old, and doesn't support many new features (For example, few flags of MiniDumpWriteDump are not supported in older versions).
This page mentions about the DbgHelp versions and vaguely mentions about distributing the DBGHELP.DLL (and other DLLs). DLLs shipped with OS must not be shipped (agreed, and no issues about it). Then it says latest DLL out of "Debugging Tools For Windows" should be shipped.
My question is: Which version can be/should be shipped with the application? Pick the latest one and assume it will work in lowest OS (XP)? Of course, I won't ship Debug version of this DLL. The "DbgHelp versions" page doesn't mention about supportability for specific OSes - so we may assume that even latest version will be supported on XP.
I would put the DLL in the application directory itself, and may conditionally call functions like SetDllDirectory. If needed, the DLL itself and/or any functions of DBGHELP.DLL may be loaded dynamically.
Related:
SymInitialize failed with error 2147483661
https://groups.google.com/forum/#!topic/microsoft.public.windbg/9V6sbsu8_js
One of the missing file error occurs as the file is deleted or corrupted. There is a different approach to its fix on the different windows versions. If you certainly need to fix dbghelp.dll missing error you need to install Microsoft Direct X follow the step-by-step method from installation of it.
I'm writing a program that needs to run across Windows 7, 8.x and 10. The program has a one (relatively minor) feature that relies on Windows APIs that are only available on Windows 10. This feature will obviously not work on Win7, and before calling these APIs I make sure that the current OS is Windows 10.
In order to use these APIs I'm forced to configure my VS2015 project to "Consume Windows Runtime Extension" (/ZW) and to set "Target Platform Version" to 10.0.10586.0.
However, this causes a problem when I try to run the app on Windows 7. I get an error dialog saying "The program can't start because api-ms-win-core-winrt-string-l1-1-0.dll is missing from your computer". I tried to installed VS2015 redistributable package on the Win7 machine, but that did not solve the problem.
Any idea on how to get this to run on Win7? I really prefer not to change all my code to dynamically load all Windows 10 functions.
The program is written in C++, and the Windows API I use are from Windows.Devices.WifiDirect namespace.
I ended up solving this problem by moving all my Win10-only API calls into a proxy DLL, which is compiled with /ZW. I then removed the /ZW switch from the main program, which then allowed it to run under Windows 7. The proxy DLL is only loaded (using LoadLibrary() call) when my program is running on a Windows 10 machine.
This solved the problem. I did have to write a few proxy functions for the DLL, but it was far lass overhead than doing that for all the Win10-only API calls.
I would still like to hear better solutions, if there are any.
It is possible to access Windows 10 APIs without using /ZW switch by using the "ABI" API. More details here:
https://blogs.msdn.microsoft.com/oldnewthing/20160629-00/?p=93775
You'll have to use APIs like "RoGetActivationFactory" and "WindowsCreateString" through LoadLibrary/GetProcAddress, since you can't link to them as they're not available on Windows 7. Don't forget to define your WINVER and _WIN32_WINNT to Windows 7:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx
That will allow you to not link to any APIs not available on Windows 7.
I’m a C++ application developer on Windows system. I’m developing an application using EGL 1.4 and OpenGL ES 2.0.
In a certain kind of a OpenGL32.DLL version, I found that a PVR error message occurred. The versions of OpenGL32.DLL that cause this problem are 6.3.9600.16384 on Win8.1 and 4.0.1379.1. And the message says :
PVR Message
PVR: VFrame attempted to use one of these functions:
PVR: wglChoosePixelFormatARB
PVR: but they are not present on you machine.
Ignore?
This message appeared when I call eglChooseConfig() or eglGetConfigs() functions in EGL API to get system configs.
I think this problem occurred because OpenGL32.dll versions mentioned above don’t support wglChoosePixelFormatARB() function.
Most of versions that I tested worked well. List of working version is :
5.2.3790.3959
6.1.7600.16385
6.3.9600.16384(1000kb)
10.0.10130.0
And list of not working version is :
4.0.1379.1
5.1.2600.1280
5.1.2600.5512
6.3.9600.16384 (720kb)
To solve this problem, I want to include this dll file in my product for a commercial use. I want to know that distributing a working version of OpenGL32.dll is possible. And can you know me the list of OpenGL32.dll version without this error and license information about OpenGL32.dll?
The issue is not about the opengl32.dll (in fact its inner working hasn't changed since Windows NT-4 some 19 years ago). Your system is simply missing a graphics driver with full OpenGL support:
The graphics drivers that are installed by default on Windows (and Windows Update) have only a very limited, stripped down OpenGL support (in fact they hardly support GPU acceleration). To get proper, full OpenGL support you must download the driver package for your GPU from the GPU vendor's website and install it manually.
Using Windows standard, automatic driver installation and Windows Update will not give you proper OpenGL support.
I wrote a C program and works fine on Windows 7 and Linux, but when I execute it on Windows XP I get the error:
"_except_handler4_common could not be located in the dynamic link library msvcrt.dll"
I researched it and some people said to delete the DLL "dwmapi.dll" which I don't have, so that's not my problem.
Some one told me to use depends walker(depends.exe) to find who is using msvcrt.dll. I did and find that pcre library is using it and there actually is a problem with it, but I don't have any idea how to solve this. Can any one help me?
Here's image of what depends walker show me:
Reason possibilities (afaiu):
a) You linked to msvcrt.dll specifically when building - this should
not happen according to Microsoft support unless you specifically do
it.
b) Some other installed or copied program/driver on your XP that
links to "wrong" version of msvcrl.dll is being triggered.
Depending on what the reason is,
here are few ideas to resolve:
1) There might be some program/driver/etc. installation on your XP
machine that has introduced "Vista/Win7 related crap" onto it. It is
said (by the internets) that PCRE3.DLL belongs to "GnuWin32 Non-system
processes". That means you can try to find it and rename/delete it. Or
delete the program you that uses it.
2) Installing the redist for XP of the C++ redistributable that you
used to build on Win7 might help. This is link for VS2005: (darn..
use google - i can only give two links per post :P)
Rebuilding:
3) Just build the file from sources on your XP machine using some
VisualStudio version you can get on it. And check those VS project
properties!
4) Fix your build on Windows7. You might be linking to
_except_handler4_common in msvcrt.dll in your Windows 7 build. Make sure that you do not do that. You can specifically instruct the linker
not to link to it in VisualStudio project properties
"/NODEFAULTLIB:msvcrt80.lib". You also did not specify what are you
using for building. VS2005, VS2008, VS2010, gcc?
Answer based on educated guesses and Jeffrey Tan research here:
and research here:
(On behalf of OP)
The problem was with the pcre3.dll, as i've told before, and i simply change the version of it, I was using the version 7.x and change to 4.4 that calls pcre.dll instead of pcre3.dll, that solve my problem if any one have the same issue.
here is the link to the correct lib:
pcre-4.4-dll.zip
I have a Win32 app developed in C++ Builder XE, which has worked great in the WinPE 2.x/3.0 environments for the past couple of years. I have made some significant changes over the past couple of months, but now that it's complete and I try to run it under WinPE I get the error message: The program can't start because SHFOLDER.DLL is missing from your computer.
Since I can't control the WinPE environment, and this dll isn't included in WinPE, my first thought is to try and statically link the necessary components. However, it appears the functionality offered by this dll is only available from the dll.
I haven't been able to find any useful information on this DLL, and unfortunately I don't know which functionality I added that now requires this DLL. I am hoping that someone has experience with this, and can help guide me toward statically linking the required components, or finding a workaround so that this app no longer requires the dll. Thanks!
shfolder.dll is used to get shell folder paths like the Desktop, My Documents, Windows directory, etc. It implements SHGetFolderPath() consistently along all versions of Windows due to differences of implementation between SHGetSpecialFolderPath(), SHGetFolderLocation(), SHGetKnownFolderPath(), etc.
MSDN explains it better:
This function is a superset of SHGetSpecialFolderPath, included with
earlier versions of the Shell. On systems that preceded those that
include Shell32.dll version 5.0 (Windows Millennium Edition (Windows
Me) and Windows 2000), SHGetFolderPath was obtained through
SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and
later versions. SHFolder.dll always calls the current platform's
version of this function. If that fails, it tries to simulate the
appropriate behavior. SHFolder.dll continues to be included for
backward compatibility, but the function is now implemented in
Shell32.dll.
The DLL itself is redistributable so you can include it for WinPE. You can also just use any one of the other functions, if they work for you and you don't need any of the special cases.