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?
The control panel that gets installed depends on the GPU detected, intel have various types of control panel depending on what generation of GPU you have, the control panel in this package is from an intel installer that still contained the control panel for older GPUs, if intel actually fixed any control panel problems but just never updated the installer packages for HD3000 due to them quickly becoming EOL I don’t know but figured I might as well include the newest control panel installer I could find. Might as well cover everything possible I figured with the package.
Any chance we could get something like this for HD 4000? Windows 11 won’t run the IGP drivers for my Ivy Bridge CPU.
@pantsaregood I don’t know what the problem is with HD4000 or have any IVB hardware to test with I’d at least need to know the specific problem(s) to at least throw some ideas around.
The version of igdkmd64.sys included in the newest official HD 4000 driver (15.33.53.5161) does not support memory integrity/core isolation. Is there a way to force a newer version of igdkmd64.sys to install so that memory integrity can function?