AMD/ATI Pixel Clock Patcher

[winterkid09]

(09-25-2016 10:47 PM)ToastyX Wrote:  

(09-25-2016 08:18 PM)winterkid09 Wrote:  Alright, I have it attached.

The debug log is baffling. Everything looks fine until it abruptly quits with error 183, which means the link already exists, but how can the link already exist? It's creating them in a separate directory, and it removes existing links before creating them.

Does C:\Windows\System32\drivers\atikmdag-patched exist? If so, is there anything in it? If there is, try deleting the atikmdag-patched directory and run the patcher again. Then post the debug.txt here.

If it doesn't exist, then I have no idea what's going on. The debug log shows it's not trying to create the same link twice, and it's not a permissions issue because it has already written to the directory at that point, so I can't think of a reason for this to happen.

I can. I used Driver patcher 1.3.6 before updating to Anniversary. Now that I'm on Anniversary, I can't UNDO what 1.3.6 patched since 1.3.6 doesn't work at all.

That might be why 1.4.1 is unhappy.

Anyway, I found the directory and deleted it, the new patcher works now. Would it be practical to add a line in the code that checks for that folder and deletes it if it exists? It could prevent the issue for some others.

[ToastyX]

(09-25-2016 10:51 PM)winterkid09 Wrote:  I can. I used Driver patcher 1.3.6 before updating to Anniversary. Now that I'm on Anniversary, I can't UNDO what 1.3.6 patched since 1.3.6 doesn't work at all.

No, 1.3.6 works differently and doesn't create links at all, and it doesn't create a separate directory either, so the directory shouldn't have existed the first time you ran 1.4.1. It must have failed for a different reason the first time. Even if the directory did exist, 1.4.1 tries to remove existing links before creating new ones, so that doesn't explain why it failed.

I did a lot of testing to make sure you don't need to undo anything. The driver wouldn't be patched anymore after installing a new driver. If the old driver file still existed, 1.3.6 would have let you restore from backup, and 1.4.1 would have ignored the old driver file and patched the new one.

(09-25-2016 10:51 PM)winterkid09 Wrote:  Anyway, I found the directory and deleted it, the new patcher works now. Would it be practical to add a line in the code that checks for that folder and deletes it if it exists? It could prevent the issue for some others.

That's one of the situations I tested. If the directory exists, it tries to remove existing links before creating new ones, and the directory shouldn't have existed the first time you ran 1.4.1. That's why this doesn't make sense.

Deleting a directory isn't a line of code because the directory has to be empty before it can be removed, so if it's failing to remove the links, it won't be able to remove the directory. There is some other failure involved here that I'm not able to reproduce.

[winterkid09]

(09-26-2016 01:55 AM)ToastyX Wrote:  

(09-25-2016 10:51 PM)winterkid09 Wrote:  I can. I used Driver patcher 1.3.6 before updating to Anniversary. Now that I'm on Anniversary, I can't UNDO what 1.3.6 patched since 1.3.6 doesn't work at all.

No, 1.3.6 works differently and doesn't create links at all, and it doesn't create a separate directory either, so the directory shouldn't have existed the first time you ran 1.4.1. It must have failed for a different reason the first time. Even if the directory did exist, 1.4.1 tries to remove existing links before creating new ones, so that doesn't explain why it failed.

I did a lot of testing to make sure you don't need to undo anything. The driver wouldn't be patched anymore after installing a new driver. If the old driver file still existed, 1.3.6 would have let you restore from backup, and 1.4.1 would have ignored the old driver file and patched the new one.

(09-25-2016 10:51 PM)winterkid09 Wrote:  Anyway, I found the directory and deleted it, the new patcher works now. Would it be practical to add a line in the code that checks for that folder and deletes it if it exists? It could prevent the issue for some others.

That's one of the situations I tested. If the directory exists, it tries to remove existing links before creating new ones, and the directory shouldn't have existed the first time you ran 1.4.1. That's why this doesn't make sense.

Deleting a directory isn't a line of code because the directory has to be empty before it can be removed, so if it's failing to remove the links, it won't be able to remove the directory. There is some other failure involved here that I'm not able to reproduce.

Hmm, I'm not sure if this will help at all, but I've attached my atikmdag-patched folder how I found it before I deleted it.

  atikmdag-patched.zip (Size: 700 bytes / Downloads: 726)

I'm not sure about the significance of the time stamp (09-14-16). The files seem to be created well before I updated to Win 10 Anniversary

[ToastyX]

(09-26-2016 02:29 AM)winterkid09 Wrote:  Hmm, I'm not sure if this will help at all, but I've attached my atikmdag-patched folder how I found it before I deleted it.

Zip files don't preserve symbolic links, so I'm not sure if those are symbolic links or 0-byte files. If they are symbolic links, then the patcher should have been able to remove them. If they are 0-byte files, then something messed up the links and turned them into empty files. The patcher only tries to remove links because I wanted to make sure this new method was safe, but maybe I can extend that to remove empty files if that's the problem.

(09-26-2016 02:29 AM)winterkid09 Wrote:  I'm not sure about the significance of the time stamp (09-14-16). The files seem to be created well before I updated to Win 10 Anniversary

That's actually a good clue. I think I know what happened. You must have used the new patcher before updating, and then the update might have messed up some of the links when it copied them over. I will do some testing to verify this.

[winterkid09]

(09-26-2016 04:32 AM)ToastyX Wrote:  

(09-26-2016 02:29 AM)winterkid09 Wrote:  Hmm, I'm not sure if this will help at all, but I've attached my atikmdag-patched folder how I found it before I deleted it.

Zip files don't preserve symbolic links, so I'm not sure if those are symbolic links or 0-byte files. If they are symbolic links, then the patcher should have been able to remove them. If they are 0-byte files, then something messed up the links and turned them into empty files. The patcher only tries to remove links because I wanted to make sure this new method was safe, but maybe I can extend that to remove empty files if that's the problem.

(09-26-2016 02:29 AM)winterkid09 Wrote:  I'm not sure about the significance of the time stamp (09-14-16). The files seem to be created well before I updated to Win 10 Anniversary

That's actually a good clue. I think I know what happened. You must have used the new patcher before updating, and then the update might have messed up some of the links when it copied them over. I will do some testing to verify this.

I'm not sure what kind of file they were to begin with, because I deleted the folder and then restored from the Recycle Bin. But they are 0-byte DAT files before zipping.

And yes, I did use the new patcher before updating. Good luck with your testing!

[ToastyX]

(09-26-2016 04:52 AM)winterkid09 Wrote:  I'm not sure what kind of file they were to begin with, because I deleted the folder and then restored from the Recycle Bin. But they are 0-byte DAT files before zipping.

And yes, I did use the new patcher before updating. Good luck with your testing!

I tried reinstalling the anniversary update over an existing installation, but that didn't mess up the links. I don't like the idea of removing files to fix a problem without knowing the cause. The patcher isn't having any issues with the links it creates, so if those are 0-byte files, then something messed up the links. Keep in mind that symbolic links are listed as 0 KB files, but the type should be ".symlink" and the icon should have a shortcut arrow on it. The strange thing is why is it only affecting those three files?

[Anixx]

Works, but dropped GPU frequency from 1300 to 212 MHz, cannot work at all, especially, drag windows.

[ToastyX]

(10-27-2016 04:43 PM)Anixx Wrote:  Works, but dropped GPU frequency from 1300 to 212 MHz, cannot work at all, especially, drag windows.

No, the patch does not do that.

[DaLy]

Hi Toasty, I want to buy a CRT monitor to have 120-200 Hz, I found that monitor


If I use VGA-to-HDMI adapter, I will be able to have high refresh rate ? I have R9 280x so I don't have VGA port, only DVI-I Dual link, DVI, HDMI and DP.

I want to use VGA Adapter to HDMI to don't buy another cables like DVI-I Dual Link, because I can't find DVI-I Dual Link...
Or I need to buy DVI-I Dual link cable + [DVI-I ( Female ) - VGA Male Adapter and use it at VGA Monitor Output ?]

[ToastyX]

(11-11-2016 01:38 PM)DaLy Wrote:  If I use VGA-to-HDMI adapter, I will be able to have high refresh rate ? I have R9 280x so I don't have VGA port, only DVI-I Dual link, DVI, HDMI and DP.

I want to use VGA Adapter to HDMI to don't buy another cables like DVI-I Dual Link, because I can't find DVI-I Dual Link...
Or I need to buy DVI-I Dual link cable + [DVI-I ( Female ) - VGA Male Adapter and use it at VGA Monitor Output ?]

Technically, the card does have VGA through the DVI-I port. DVI-I means you can use a passive DVI-VGA adapter/cable, but if you plan to upgrade video cards in the future, newer video cards don't have this.

You can use an HDMI-VGA adapter, but keep in mind that HDMI-VGA adapters are signal converters, so the adapter will have its own limitations. Many HDMI-DVI adapters can handle up to 225 MHz pixel clock, which should be enough for that monitor.

Keep in mind that you'll only be able to get higher refresh rates at lower resolutions. Based on the specs on the box, it should be able to handle 1024x768 @ 115 Hz and 800x600 @ 144 Hz, but you'll have to add them as custom resolutions. You shouldn't need the patch for this.