Looks like the Catalyst version isn’t being correctly stored for some users on the recent 13.12 WHQL release. This has happened before and it’s absolutely nothing to be alarmed about. The only time this would even matter is when a game or application is using this number as a version check such as Battlefield 4, but that is a problem in itself as you’ll notice that this number is merely a registry string.
As a user, all you need to do to change the number is to go into the registry like the example shown above. You can see how you can put any text in there. Many applications in turn read that string and I say it’s poor practice on their part.
The correct driver version number to look at is the packaging version. You can even see the date in its numbers! This is the only true way to tell if your driver has been installed. You could also simply look at the dates of the driver .DLL files. I can’t believe how many people are falling for this in forums, they’re wasting a whole day reinstalling things, it’s ridiculous. Few people seem to bother with any real (not to mention FAST and EASY) troubleshooting, ironic when they do it right with hardware issues. You don’t replace the tower if a component is acting funny, software is no different.
By the way, the Nvidia Forceware driver is the same. It also uses a string for the basic number that many applications read.
UPDATE 3: It’s now missing from both the profiles .blb and the dx10+ .dlls in the 14.1 mantle beta. Not that it appeared to be needed in the first place as ‘HighPerfGPUAffinity’ doesn’t sound like it’s doing much.
UPDATE 2: It’s in the driver .dll files now. Hex edit atidxx32.dll from 13.11 beta 6 and go to 0x69ae34.
UPDATE: In the new 13.11 Beta 3 leak, hex edit the .blb file, go to 0x192a8, GTA5 is there again (was missing in beta 1).
Looks like more 64-bit games are coming outside of Battlefield 4? Don’t think this suddenly means GTA5 magically comes out real soon, developers/porters also need working drivers for their games. I’m still expecting the usual +200 days after console launch.
So a few months ago, maybe when 12.10 CAP 1 came out, you may have noticed some of the AMD pre-defined crossfire profiles do not appear anymore in CCC (and you know they used to be there). What seems to be happening is that CCC is falling back to the CAP that came with the currently installed driver, which is located in the system folders of Windows.
This is certainly a problem for legacy users stuck on a driver branch and default CAP made in April 2012. Hawken for example only appeared in later CAPs and you need to tell CCC to load the profile since it doesn’t match the game exe.
So what’s the solution? Might as well overwrite the driver CAP with the latest one since we know that’s what CCC is loading.
Let’s start with renaming atiapfxx.blb in your system folders of Windows: C:\Windows\SysWOW64 and C:\Windows\System32. Just put an -old at the end or something so that you can rename back if there is a problem.
Install the latest CAP then go to its folder, something like C:\Program Files (x86)\ATI Technologies\Application Profiles\. Copy atiapfxx.blb and paste it into the two system folders from earlier.
Restart your system and now your CCC will display the new profiles again.
There was a related bug posted on forums where ALL pre-defined profiles were missing for some users of newer cards. I’m not sure if this method can also fix that issue as I’ve never ran into it.
UPDATE 2: Instead of running the initial installer, you can use 7zip to browse and extract only the the .dl_ files you want, basically a much more sane step 1 and 2.
UPDATE: To expand every file in the current directory, type ‘expand -r *‘ and you’ll save a ton of time.
Since this comes up pretty much at least once a month on forums, I might as well write down the steps for reference. I assume you’re running Windows of course.
For leaked betas, usually you would skip step 1 since they come in an archive instead of an .EXE installer. Let’s take a look at the 12.8 WHQL package for Windows Vista/7/8 in this example.
Step 1: Run 12-8_vista_win7_win8_64_dd_ccc.exe and it will display a temporary path where it will extract the installation files. If you want, you can change it to something like H:\12-8\ for example. Note this path down as we’ll need it next, click ‘install‘ and once the Catalyst Install Manager appears, cancel it.
Step 2: If you go to the temporary folder from step 1, you should see files like setup.exe and some folders like Bin64, Config, Images, and Packages. Navigate into the \Packages\Drivers\Display\W86A_INF\ folder and then hold shift+right click the B143900 folder. In the context menu you should see ‘Open Command Window Here‘ so select that and now you should have a command prompt sitting in the location of the driver files.
Every file that ends with a _ will require you to expand it so that it can be usable as an actual file. For example, let’s expand atiumdag.dl_. Type ‘expand atiumdag.dl_ atiumdag.dll‘ (press enter to execute the command obviously) and you should now have the complete .DLL file appear in the B143900 folder.
That’s the gist of it, now you can copy atiumdag.dll to a game folder or just keep it for archival purposes in case you need it in the future. This is a much quicker way to test or use different driver versions without installing whole packages for the system. It’s quite handy when a certain game is known to work better on a specific driver version, simply hack up your own fix and you’re done.
Tip: In the command prompt window, you can press TAB to auto complete text, so if you type ‘atiu’ then hit TAB, it will automatically fill in the rest of the filename. If there are multiple files with the same beginning, just keep pressing TAB to cycle through them.
Some Useful Vista/7/8 .DLLs
atiumdag.dll – dx9 32bit
atiumd64.dll – dx9 64bit atioglxx.dll – opengl 32bit
atio6axx.dll – opengl 64bit
atigktxx.dll / atig6txx.dll – additional 32bit / 64bit opengl files that may help fix very specific games if the above does not aticfx32.dll + atidxx32.dll – dx10+ 32bit
aticfx64.dll + atidxx64.dll – dx10+ 64bit
Most games are 32bit so you would almost always be dealing with those files. Plus this technique of using a driver file from a specific package works for applications as well. Let’s say your 64bit Photoshop always crashes when opengl is enabled on every driver after 10.4. You would expand atio6axx.dll from 10.4’s package, since you know it works fine, and place it where the 64bit photoshop.exe is located.
Finally, if you’re legacy like me, you can’t really use newer files where support for your card is dropped. The same is true for using files that were compiled before your graphics card was released. The code simply is not there and you can see it in the filesize difference.
So this has happened before a couple years ago. Luckily it appears to be minor. Just open a close a game and your secondary crossfire gpu should be back to 2d idle clockspeeds. I tried it on a couple DirectX9 games and it worked fine.
I discovered this some months ago, when vsync and crossfire are enabled in old UE2 games, the combination will cause strange framerates and massive stuttering. So you should disable CF by disabling Catalyst AI, rename the game to ForceSingleGPU.exe, or make a profile in RadeonPro or the profiles feature in CCC (starting from Catalyst 12.1).
This seems to affect the standard UE2 games, not the heavily modified ones like Bioshock or Duke Nukem Forever. It does not matter if you’re enabling vsync with D3DOverrider, an in-game option, or the engine .ini file, it all results in the same stutter. I’m noticing it in Unreal Tournament 2004 for example.