Nope, just some general cleanup @boombastik. I don’t think there is a way to fix OGL on HD3000, people are stuck with W8.1 or W7 for OGL to work fully TBH something smells a little funky with the lack of proper driver support in W10 for HD3000, the IGP is less than 2 months older than HD4000 if you go by announcement dates but the latter is fully supported in W10. Considering this keeps coming back to bite intel its even more surprising they didn’t make a proper driver but at the same time this is the same intel that back then couldn’t even be bothered to make a driver that fully supported the IGPs capabilities (OGL 3.3) limiting it to OGL 3.1. If there are any linux people around they might have dug around and found the answer to the W10 issue as thats the sort of thing they have to do a lot more of.
There is a bunch of info about the HD 3000 and other older Intel iGPUs and OpenGL support at this link.
The main takeaway is that Microsoft and Intel are both somewhat responsible for this.
The Intel OpenGL driver in ig4icd64.dll or ig4icd32.dll tries to check the Windows OS version and refuses to work if it finds a version number that it doesn’t expect.
Windows used to have version 5.0 for Windows 2000, 5.1 for XP, 6.0 for Vista, 6.1 for Windows 7, 6.2 for Windows 8, 6.3 for Windows 8.1. The driver checks the major version number, but only checks if it’s 5 or 6. If it’s any other number it returns with an error. It gets the version number via a GetVersionExA WinAPI call.
With Windows 10, Microsoft changed the version number to 10.0. However to maintain backward compatibility GetVersionExA still returned 6.3 unless the application explicitly declared itself Windows 10 compatible in the application manifest.
This presents the problem, when a newer application that declared Windows 10 compatibility loads an older DLL, if the DLL calls this WinAPI function it will get version 10.0 back. But an application that doesn’t declare itself Windows 10 compatible could load the same DLL and have the function return 6.3 on Windows 10.
The Intel DLLs check the Windows version number like this in assembly:
- get the major version number from Windows API
- subtract 5 from it, if it’s now zero assume Windows XP etc. legacy path
- if it wasn’t zero subtract one, if it’s now zero go to Vista, 7, 8, 8.1 path
- if it wasn’t zero this time either return with error, this happens on Win10
So here is the issue, if any modern application that declares Windows 10 compatibility in the manifest tries to load the Intel OpenGL DLL it will fail to load.
The first link talks about solution strategies like modifying the manifest file for applications, lying about the OS version via a compatibility layer etc.
You can also modify the DLL itself to fix Intel’s version check algorithm. The outline of this process can be found here in this github thread. You find the part in the DLL and then edit it in a hex editor.
One way to fix the DLLs for this driver version:
- for the ig4icd32.dll: Find the following hex string in the file: 48 75 DD A1 24 90 and change 75 DD to 33 C0
- for the ig4icd64.dll: Find the following hex string in the file: FF C8 75 DB 48 8B 05 86 and change FF C8 to 33 C0
This way the size of the file doesn’t change, offsets don’t change and this will make these DLLs accept any major Windows version 6 and above.
Here is what I am not sure about: how would driver signature enforcement work with these. In the latest released original Intel 4229 driver this DLL doesn’t have a digital signature, however in the 4459 version from Microsoft it is signed by Microsoft. I completely removed the signatures with Microsoft’s signtool on the 4459 versions as they become invalid due to the modification but can’t really test if that screws with anything, like SecureBoot.
The modified 4229 version DLL works on my Core i5 2467M equipped notebook under Win 10 64-bit as far as I can tell with some OpenGL extension tester programs (I used GPU Caps Viewer as it can actually display some 3D tests that use OpenGL 3.x functionality). It supports some limited set of extensions beyond 3.1 too although it reports 3.1 compatibility.
If you could confirm that this solves the OpenGL issues that would be great.
I will try the 4459 versions. I don’t think that signature is a problem as secure boot don’t supported in sandy bridge motherboards.
@hix3r I tested it and it work with 4459. I simply replace these two files and now i have support with opengl 3.1 in windows 11.
@hix3r I don’t have the system that used HD3000 - literally sold it yesterday, but I will get other 2nd gen intel systems in the not so distant future so I will verify these DLLs work on W10 when I do and post back here. When I do get another 2nd gen system I’ll insert the DLLs with my custom install package to see if everything installs fresh as it were and we can go from there but it certainly sounds like you found the fix myself and boombastik couldn’t. I’m glad to know I was pretty much on the money though regarding the DLLs needing some rewriting to get them working, did that provide you with the clue you needed that I wasn’t seeing? If so I hope it made things easier for you. I find it quite dumbfounding that something that turned out to be as straightforward as it is to fix never got fixed by intel or MS in the servicing driver, sure the hardware isn’t exactly the newest but it is still capable and nobody could consider the hardware old at the time of W10 first releasing so… yeah, really mind boggling the issue didn’t get fixed by intel or MS. Well, maybe not mind boggling, if I apply my pessimistic mindset here I’d say the problem intentionally wasn’t fixed by intel as a way to try and increase sales of their (then) newer hardware.
Everyone can rejoice! HD3000 IGPs have 100% OGL support in W11 and (most likely) W10 systems now
Thank you for testing, that is great news.
Yeah, it was weird that the DLLs got installed fine with the driver but somehow applications couldn’t use them that lead to some googling.
I wasn’t the one who found this patch, originally this was discovered by Minecraft developers when the LWJGL Java library used by Minecraft started crashing on Windows 10 back in 2016 on Intel IGPs. They found out that this was caused by a newer Java version they started using which at the time started declaring Windows 10 compatibility in it’s manifest file. If you switched to an older Java version everything worked in Win10 which was the solution they recommended in the end but others found ways to patch these DLLs.
Leave it to Minecraft players to reverse engineer driver DLLs so that the game runs on their hardware…
I think the lack of support for SB is due to the fact that IVB IGPs and later use a different DLL for the OpenGL ig7icd64.dll, ig7icd32.dll etc. which suggests there are some architectural changes in the IGPs and how the OpenGL functions are implemented. So Intel decided to only keep supporting that line forward, maybe it was easier or simpler.
Technically these ig4 DLLs still work without modifications under Windows 10 if they are loaded by a program that doesn’t declare itself Windows 10 compatible. So you could use them under Win10 but only with older programs. I think they decided that that’s good enough for a servicing driver, which yeah, is definitely not ideal.
@hix3r thats whats really strange to me yes there were architectural changes between HD3000 and HD4000 but initially intel released combined driver packages to support both IGPs meaning ig7 and ig4 DLLs are present in the same installer package a lot of the time it would have taken someone at intel or MS literally 60 seconds or less to make these hex changes in the DLLs
I guess this sort of explains why when someone from the compute side on the Mesa project came in when I was making some initial enquiries on this why my questions got immediately shut down, kinda seems like someones feathers somewhere got ruffled perhaps.
All has ended well however, the enthusiast community has done it again. Viva winraid!