Kissol wrote:jmjsquared wrote:Perhaps you should create your own thread to share your opinions. 
Thanks for your suggestion.
EDITED:
P.S.: To Moderators: The issue submitted in the first post is not related with Full Uninstall definitely: 1- The app. installed doesn't require reboot when uninstalling; 2- Poster did the same request in 'Comodo Programs Manager' forum... - 
- 
- 
- [please see here...]. Issue resolved and mainly clarified. - 
@kissol - Not only are you full of bad advice and bad manners in earlier trying to hijack my thread but, you are also full of something else!
If you look at the dates of my posts, you will see that, only after not making progress here, I sought further help by going to the support forum of a rival software publisher who includes a device-driver-uninstall utility in its tool. Full Uninstall does not offer such a specific sub-tool in its utility and, therefore, despite Konstantin Polyakov's best efforts, would be limited in offering SPECIFIC guidance in addressing a DEVICE DRIVER'S uninstall problems.
My logic proved valid.
Now, contrary to your childishly vindictive assertions here's what REALLY transpired:
My problem began on June 10th
USING ONLY FULL UNINSTALL. After two days of trying to sort things out myself, I posted here at Chemtable asking for help. Konstantin responded amazingly quickly but still not quickly enough for me. So, while waiting for his/outside help, I continued to help myself. Using
SpinRite, I got the original hard drive working again, although, with more than
six reallocated events recorded by HDTune in the three hours before its initial failure, it was ready for the garbage. That was the reason I replaced it with the cloned drive mentioned in my original post in the first place.
So, then, with my
backup not booting, due to Full Uninstall's having removed "something" required to complete the subject driver's uninstallation across a reboot, in order to get that backup working again, I installed the rival uninstaller's program on the resuscitated HDD and put that into one of the several laptops I have just lying around, in this instance a Dell Inspiron 1545. You'll note, from my original post, that I use Acronis TrueImage to do my backups/clones and it permitted me to install that HDD to the slightly different hardware with no problem. Remember: I needed to be able to determine
exactly what a third-party's uninstaller does at removal-across-reboot and, it turns out,
I was absolutely correct in trying this approach. The Mobile Device Driver was still installed on that HDD (as explained in my original post) and so, I proceeded to uninstall it using the rival's utility. HOWEVER, in order to mimic Full Uninstall's routine, this time I DID NOT disable the driver in Services prior to uninstall.
Originally, Full Uninstall had run the driver's native uninstaller, as expected and advertised. HOWEVER, when I allowed it to remove all traces PRIOR TO REBOOT, it also removed an executable (a trace) that was going to be called at boot-time to finish the uninstall. hen that executable could not be found, my system "froze". Similar to a good anti-malware program, Microsoft designed its Mobile Device Driver uninstaller to finish its work BEFORE the OS fully booted. Of course, that could not happen because a "piece" of the driver's uninstaller had already been deleted and, so, Windows could not proceed!
Sure enough, when I used the rival's device-driver-specific uninstaller
AND removed traces BEFORE reboot, the same problem recurred.
HOWEVER, since the rival's uninstaller is designed to create a backup for reinstallation (two files, in fact)
this time I had some idea of where to begin to look for the problem. Apparently, unlike Full Uninstall's routine, this rival's program does not rely exclusively on the native uninstaller for across-boot activity; rather, it uses its own executable which refers to the aforementioned two-files to complete its job at reboot. When, with the help of a Moderator at the rival company's support Forum, I located and removed the rival-specific executable, I got the "old" system working again; ie., I could get into Windows and cleanup the driver's 'partial' uninstall.
Only
then did I tackle the "real" system, which is
NOT the system to which you so happily and foolishly refer.
DependencyWalker and Nirsoft's
UserAssistView made it relatively easy to do a little forensics on the system I originally posted about and follow the path that Microsoft's native uninstaller WOULD HAVE REFERENCED at reboot.... if it had not been deleted by Full Uninstall as a "trace". I used those two tools on the "old" system, located the offending file and, then, deleted it from the "real" system and broke the freeze. So far, no loss of data, programs nor anything else. And,
unlike with the system you mis-refer to, no broken antivirus or email programs because,
IF YOU HAD READ CAREFULLY, you would have seen that I DID not do the same things mentioned here!
THERE WERE TWO SEPARATE MACHINES USING TWO DIFFERENT PRODUCTS!
Again, I must compliment myself for my ingenuity, otherwise, I probably would never have gotten thE "real" system working again. Fact is, the Microsoft uninstaller refers to an executable named "setup.exe" located in the Windows folder and there is
NO WAY I would have ever figured that out without following the course I did.
I have taken the time to explain myself here only out of respect for
Konstantin Polyakov and his much appreciated efforts to help me. For you, I have nothing but contempt. You should always check your facts three times --or more-- before speaking ill of another. The fact that you post meaningless drivel that is so full of mistakes, misinformation and pandering nonsense is almost forgiveable. But, your cowardly use of the veil of the Internet to slander another, to me, makes you worthy of no more than two words: Go away!
) at a more appropriate time and place.