Search options (Page 50 of 77)

Odd. The driver you linked too is almost identical to the one I'm currently using, only does this one have more .inf files... so it supports more devices.

Could you please check which driverversion is installed? I think the wrong driver was installed...

EDIT: and is your sound working ok?

No match for your HWID could be found in the .inf files. I'll check what's wrong.

By looking in the .inf file. You will see that your device is supported by the driver in the D\M\IN\1\O directory. (Just verified that.)

I assume you've installed the driver manually now? Since it seems to be installed just fine according to your hwids.txt.

driver update system?

It seems the complexity was higher than anticipated. Especially because none of the UBCD4WIN could tell me the exact best method to use: I had expected that they had some nice doc about it or something. So it will take longer. Can't give you a date.

Interesting indeed! They use the SATARAID driver, while I'm using the 'legacy' driver. This method has been working for a long time now, so I wonder why it no longer works...

I agree. But it's just not yet implemented, what amazes me very much, since that should be one of the basic features... We'll just have to wait until it's implemented.

This crap never works as it should... continue discussion here.

@ricktendo64: yes, they already were excluded.

@jtdoom: no.

It IS present. Just not this version... Will update it.

I won't make that an option. But you can easily accomplish that. You've got two method:

1) remove the control panels from the Driverpacks. This saves space too, but involves a lot of work for you.

2) just remove the sections from the DPsFnshr.ini file that you don't need.

Fixed the KTD thingie.

The algorithm that causes this 'odd behaviour': since some files can sometimes be locked by processes, deleting everything could fail. Unlocking everything isn't very simple and most of the time it's not recommeded to do. Especially the Finisher, that executes setups for control panels, will result in file locks. The setups that are started by the Finisher, sometimes call child processes and thereby end the parent process we called. Therefore the program thinks the setup has been completed and thus continues. But what if we start deleting while the setup is actually still in progress? Then an error would be thrown that says the directory cannot be deleted.
That's why I've gone for this alternative. Each file will be deleted separately, and if it fails, then the Finisher will wait 5 seconds. And another 5 seconds. And...
The entire deleting process, that includes both the deleting of the files AND the time lapsed due to waiting for the file to be unlocked, cannot be longer than 10 minutes or the Finisher will end it. Instead, it will write a new value to the registry that will delete the directory after the next reboot.

This was a mechanism that SHOULD work without a problem, but apparently some files aren't geting released at all... I will reconsider my strategy...