Display Driver Uninstaller Thread

Yes it has the potential to help on this.
Also note that this removal is an option checkbox. While using this checkbox, you must absolutely reboot.
(so I disable the 2 others buttons for cleaning if this checkbox is checked.)

Ill answer more question tomorrow time for me to go to bed I work early tomorrow morning.

 

I will attempt to manually corrupt my system as I did in the past by performing a forced removal of all GPU related services followed by a forced removal of Windows Store Driver. Then I will attempt to to add and remove a place holder service to get the driver up and running again.

EDITED
I think I may be able to replicate the broken device issue where user are able to re-install any driver but cannot uninstall drivers that become broken due to a bad install.

Also removal of those drivers can probably be done through a forced removal.

Other Thoughts
I think there are at least 3 reasons Drivers become broken.
-The first is due to the Driver Store being deleted in which it's associated Oemxx.inf is left behind.
-The second would be the Driver Store being broken while still containing it's associated Oemxx.inf
-The third is due to a forced service removal from the registry. When this happens users are unable to install or reinstall drivers.

Ok, so this method attempts to get the driver to fully load into the system by performing a system restart but if it's done only with the restart option then the service removal can be automated when choosing to restart or shutdown the system.

So it would be best to implement the check box along side the rescan option. This means when the check box is selected for Users using the Rescan option DDU will display a button telling those Users to perform a Recommended System Restart by clicking the button. But this will only happen after System is done cleaning.

Post is a bit confusing....It's basically saying to implement a method so Users can check to see if driver removal is successful before performing the system restart and implement an Option for Users installing a new Graphic Card.

 

Your 3 reasons are valid. especially the third one that will prevent driver installation by a .inf error message(or something similar) (driver sweeper kill the service and cause this inf errors.)

For the checkbox forced reboot you got it a bit wrong.
I simply ask windows to remove the drivers services but they cant be removed directly in normal mode, so they are flagged to be removed on next reboot. So if we don't restart the system and the user reinstall a new driver while the service being flag for removal will probably do a big mess after a reboot.
So this is why im forcing the restart. Its a must!
I think that if we are in safemode, we can avoid the restart but this is something I must test.

Others thought.
If the driver removal is not sucessfull because of
-Application crash (the system wont reboot as it has not reach that final point in the code)
-The program finish to run but didnt remove everything (DDU log after reboot can be seen)

-I think I can let the shutdown option availlable. Ill have to see if I can force a shutdown without using the windows 8 hybrid shutdown as its not a real reboot/shutdown. If I can work around, ill reactivate the shutdown button.

Also were you able to recover you system a bit with DDU v7 ?

 

Are you by chance familiar with the SC command? This command allows you to create remove, control, stop, pause and delete a service. Using this method should allow you to remove a service after the driver is uninstalled (It's capable of removing the service even if the driver is not uninstalled) and no longer in use. This command is actually a command I recommend using. Previously when I tested the forced service registry removal I found the service is still in use and even when removed. However when using the SC command the service gets completely uninstalled without leaving a single instance behind. Thus user attempts to install their driver installation can proceed as normal. But this of course does not apply to the forced registry removal as the service continues to run in the background. Therefore when users attempt to install or re-install the Display Driver drivers they experience a BSOD or with a message stating the driver cannot be installed.

Other Thoughts
The Shutdown Command currently implemented in DDU is a real Shutdown.
My reason for saying this is due to having an Advanced Boot Menu that will only appear if the System is restarted or Shutdown. When used with Hibernate the menu does not show up and will continue to launch Windows without prompting user to select an option.

 

I use the "sc" command to remove the service And it cannot remove-it without a reboot (its flagging it for removal on the registry as its a special service. Windows must hold it somehow.(but I didnt try a stop before... I should try this and then maybe we could avoid the reboot...Will try this when I get home)
Thanks also for confirming im doing a complete shutdown, I wasnt sure if it was the case. So in 7.1 'll reactivate the shutdown button when we delete the hidden service.

I also did a small change on the removal with devon. I use disable now before remove. It seem to help nvidia a lot. It was 2x slower to remove before. I think it also fix an issue some users were having that it screw up the pci-e root device.

I only have 1 strange issue with some users. On rare occasion, the driver wont get remove by devcon remove. after a reboot or another try, it does get remove, so ill have to log the actual outbput of devcon disable and remove to see whats going on.
I only got report of this for nvidia users tho... and only saw this 2 times... so... bad luck? oh yeah saw titanxx with a similar problem with his audio device.
Ill also have to ask shaddy where is at with the auto update/notification feature. I wanted it to be in 7.0 but I also wanted 7.0 to be release before the nvidia next driver...

Other thought
Can you provide me (on a healthy system with current amd driver or not too old one) a regkey list of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

SInce I dont have an amd machine anymore, I need to check those key to be sure I catch all amd services.

 

It's quite strange that you would experience that as the service get completely removed even when the driver is installed and running.

Services,
sc delete "amdkmdag"
sc delete "amdkmdagA"
sc delete "amdkmdagB"
sc delete "amdkmdagC"
sc delete "amdkmdap"
sc delete "amdkmdapA"
sc delete "amdkmdapB"
sc delete "amdkmdapC"
sc delete "AtiHDAudioService"
sc delete "ATI External Events Utility"
sc delete "AMD External Events Utility"

For some reason the "Atierecord" Service does not get removed so I decided to exclude the removal of this service. I will test it out with a forced registry removal to see if it deals any damage to the system.

Other Thoughts
In what stage does the audio device bug occurs? During the Inf removal or the the very first removal to deactivate the driver?

I know Multiple Devices can be the cause of drivers not being removed but DDU already contains removal for Multiple Devices. Or did you by chance only implement it for the Display Driver?

 

I do not disable the audio device yet. I only disable the GPU as I wanted to gather some feedback as if it helped users.

The issue is Titan29 2pages back. But he hasnt comeback and answer so fixed or not I dont know.
So ill have to log all devcon sucess / failure to know exactly what is going on and avoid asking the users to manually do the command and asking result.
In 7.1 ill implement the disable to audio device too. maybe this is a beter way to do things than forcing a remove. The disabling before remove on the GPUs really really helped with my GTX 690 (speed wise) and it seemed more clean.

 

Fantastic job Wagnard and the whole DDU crew, excellent little utility

 

Iv'e used the disable command before but speed improvements went unnoticed as the cleaner already did a fast removal. If you do implement it in the next version of DDU I'll test it to make sure it does not result in a reduced performance for AMD Users.

 

If you don't see any slowdown with 7.0 I do not think 7.1 will be slower as 7.0 already have the disable on the gpu so I doubt the audio will make it slower but we never know.

 

I don't think it would cause a decrease in performance either but bugs do occur when you least expect it so I tend to keep my fingers cross.

Other Thoughts
I managed to limit inf removal down to a single inf so a forced removal of drivers can be implemented without affecting other drivers. While the forced removal may be capable of cleaning up drivers that are broken in the driver store it's not capable of removing inf's and associated pnf files when the files in the Driver Store does not exist. (Will test this out now)

UPDATE
Before I perform the test I ran into the service bug and could not reinstall the driver until the stop command was used.

 

Thanks :thumbup:

 

I will send you the results via Skype.

 

I don't think that it's not polite trying sending a private message for this information....maybe he forgot to let you know....

 

Release 7.1

-DDU now disable devices before removing them (help on multitude of things)
-More logs on the .log
-Gui log is more user friendly.
-Also remove Monitor and hidden monitors (some system have more than 100. A new monitor is installed after each driver update for those who didn't know)
-Thanks for the 2 users who donated, its appreciated.

 

Which version does not contain the Disable before removal feature? I want to test the latest method and the previous method to see if it results in reduced performance.

 

7.0 have the gpu disable 7.1 have gpu and audio disable. anything before doesnt have a disable.

7.1 have a little performance problem for updating the gui. Ill look into this for next version.

 

Release 7.2
-Fixed a bug that could prevent the driver store to be cleaned.

 

Ok thanks, I will test it out later today when I get home.

 

I would like to ask you if you could support Intel-GPUs in the future.