@boombastik after some more investigations it looks like the OGL DLLs are flat out broken or incompatible. The DLLs do in fact get installed (just check syswow64 and system32 folders) but they don’t load, trying to register the DLLs via an elevated command prompt by typing regsvr32 ig4icd64.dll then trying to register the 32bit DLL in syswow64 results in the same error being spat out; the module failed to load. Ergo, the installer and inf are perfectly fine the biggest culprit is likely Windows itself as up to build 1809 or so you can likely get the DLLs working with a compatibility administrator database file. Beyond that, literally nothing works unless someone can debug or rewrite the OGL DLLs for W10. You can experiment slotting in other intel OGL DLL files weather that be ig4icd64 or ig7icd64 (the latter needing to be renamed and edited with a hex editor) then using regsvr32 via an elevated command prompt to try and fudge something together that’ll work but ultimately I think the only viable way to fix this issue is for someone to take the DLLs and debug or partially rewrite them so they will work on W10.
EDIT: There is a possibility that igfxsrvc.dll or igfxsrvc.exe are to blame for the OGL DLLs not loading too.
Slightly updated install package to clean things up a bit and rewritten readme. Unless someone can fix the OpenGL problem this is as good as these drivers get.
EDIT: Small update on the OpenGL issue, there is a (very) faint glimmer of hope that this problem can be fixed. I’ve chatted with one Mesa dev from the media side hopefully one will come along from the compute side. @boombastik I’ve also discovered that with no HD3000 driver installed at all that Win10 defaults to OGL 3.3 in compatibility mode through Mesa 22.0. There is a tiny bit of hope yet 
Hmm… well because I’m obsessive over these kinds of things I decided to disable driver signing and try to do some hoodwinking. If the supplied OGL drivers won’t work I figured maybe I could “patch” the issue with different DLLs. I was a little surprised to see that even pointing Ivy Bridge DLLs in the INF for HD3000 don’t seem to work either and HD4000 IVB parts are supported on W10 so we are back to this being a Windows problem or the OGL files with the driver are completely borked @boombastik. Still looking to see if I can get some sort of workaround working but if I do it will absolutely require the use of a modified INF so people will have to disable driver signing in W10, if that ends up being the case I’ll include a few batch files and a watermark remover for lazy people who can’t be bothered enabling/disabling driver signing all the time but don’t want a nasty watermark either.
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.
You can download these two DLLs for driver version 4229 here and 4459 here. These are modified as described 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.
EDIT:
@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 
@boombastik
Thank you for testing, that is great news.
@ket
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! 
@ket , @hix3r
I have some more good news. I took your driver ket and i put the two dll 4549 opengl files with the removed sigatures that provided from hixer.
Upon install it says at the half of installation that the drivers is not digitally signed and ask you if you want to continue or not. You simply accept the intallation and after restart the drivers continues to work and in windows device manager is reported as Microsoft Windows Hardware Compatibility Publisher and don’t lost its certification. So all work as expected you only need to replace this two files in your modded driver ket.
The reason that the driver don’t lost its digital sign is that upon load it seems to only check for modification
this six files that continue to have signature : igdumd64,igd10umd64,igd10umd64,igdumd32,igd10umd32,igd10umd32
the above got daz3d working on a hp probook 6460b with hd graphics 3000; before the above daz3d would not run because opengl was at 1.1 it said.
I’ll put a pack together for 4459 when I get a moment just for convenience. Good to know this nut is well and truly cracked the HD3000 is perfectly adequate still for the majority of tasks there’s no reason for it to get the hate it did/does from intel. In case anyone is wondering no, I don’t ever delete things like this the link will remain live for as long as mega is going.
Learned that you can expose some of the features(HD 3000) to win10 by using the Compatibility Administrator from windows:
I would add to the above link info; save your fix(sdb file). Reload your fix back into the CA from where you saved it and right click on it and click install to install your fix. After I used the CA as explained in the above link I was able to remove the opengl32.dll by Federico Dossena and daz3d still worked. The fix worked. You may need to start your computer.
The fix (CA) did not work for blender 3.2.1. Blender wanted openGL 3.3. Federico Dossena work for Blender 3.2.1 However take note when you install blender the link on your desktop is to the blender launcher – blender will not start! Go to blender DIR where Blender, Blender launcher and your Federico Dossena opengl32.dll are located . Double click on the blender.exe file; blender will start/open – it did for me anyway.
Intel hd3000(sandy bridge) by way of Federico Dossena has openGL 3.3
The Windows driver supports up to OGL 3.1 but the hardware is capable of OGL 3.3, intel were too lazy to write a Windows driver for the hardware to utilise all of the OGL capabilities there isn’t much we can do about that. These fixed drivers basically eliminate the need for the compatibility shim in 95%+ of scenarios. I tested the compatibility shim fix myself anyway and having to apply it on a per application basis is a massive pain in the arse, even then the shim fix won’t work for all software which is why this driver was born, outside of niche scenarios (eg; software wanting OGL 3.3) this driver restores full OGL functionality, fixes hardware encoding acceleration, possibly some other bugs too.
EDIT: Also updated link in first post with the new all-in-one driver package, no need to do anything other than install the driver.
that’s because many boards with just sandy bridge hardware were still using legacy bios (non-uefi). uefi & secure boot came when ivy bridge hardware were released
also, does this driver also support HD2000 (which is also part of the sandy bridge series)?
both HD2000 & HD3000 are of same generation
HD2000 hasn’t been tested AFAIK only HD3000 but if intel uses this driver for HD2000 it’ll work but other OGL DLL files might need patching.
Hi. Thanks for the updated drivers. However, as I use a HD3000 (Lenovo G570) as a daily driver, here are a few observations from my research on the OGL and “Why did no one do this before?” thing.
Although I never faced any issue with OGL incompatibility, reading the posts here, I can assure that Windows 10 pushes only 4459 drivers across W8.1 and W10/W11. That being said, they lack OpenCL and intcdaud drivers. Being OGL 3.1, more capabilities can be added. Refer this video accordingly, AFAIK the person were installing mesa drivers of sorts… 
Intel Hd Graphics 3000 support Opengl 3.3 - YouTube
Now, an attempt was made 2 years ago by Nightmayor, an user at TenForums.
[Custom Driver : Intel HD Graphics 2000 3000 Extreme Plus -by nIGHmAYOR (Custom Driver : Intel HD Graphics 2000 3000 Extreme Plus -by nIGHmAYOR Solved - Windows 10 Forums)
Out of curiosity, it would be wonderful if any expert here can explain what the differences are between these two…
Cheers! (IG I’ll post more on this topic later…)
EDIT:- Last but not the least. Does the compatibility pack offered by Microsoft for Windows on ARM PCs work? Apparently, it supports x64 PCs as well (as per some online “research” of sorts) and I’m starting to question that xd
EDIT 2:- Linux seems to not be the only option, as compatible MacOS versions with appropriate kexts (High Sierra) have higher OGL versions :0
I don’t work with Linux so can’t comment on things that side, I can say though that this driver does include OpenCL however it is CPU instructions only. As is my understanding with the Nightmayor driver the focus was just on minor tweaks and trying to squeak out a bit more Quicksync hardware encoding performance. You could try switching the MediaSDK folders with this package and Nightmayors but chances are any improvements will be minimal.
That’s totally understandable. Thanks for the clarity. Now, my last question (for now). I see an update of Intel Control Panel in the original post (Intel Control panel 8/10/2020). However, the intel graphics configuration panel that I see on my laptop is still the same. Did the UI not change even after all these years? or did Windows Updates secretly override the things on my Laptop (even after explicitly disabling it) through it’s stupid auto(crap)matic driver updates?