OK, so it seems that just about every time i want to uninstall/upgrade a program on my tilt (not cracked, only bypassed the att crapification...er, customization).
what happens is, certain programs (most recently cetwit) will not fully uninstall when i goto remove them from remove programs. it says this and asks if i wish to remove the program from the list of installed programs, and i usually say yes. that program is still listed when i goto start/programs, and the program files are still safe and secure in the program files folder through file explorer.
the worst part is, when i try to reinstall/install an updated version, it shows two icons in my programs list, which is very frustrating...enough so that it causes me to hard reset and reinstall everything over again. i've run registry and junk file cleaners to no avail.
is there any way to COMPLETELY remove a program in this situation, or am i required to hard reset each time it happens?
maybe here i will also ask for a good registry cleaner that knows what to kill and what to leave...
sktools wiped out some important things, had to hard reset and start over because even my backup app couldnt fully recover.
Get a file explorer, delete the program's folder in Program files, delete the shortcut in the start menu and most of it is done. You can then use a reg cleaner to remove the last remains in the registry.
That has happened to me with a couple of programs, I'd blame the programs rather than WM.
I have a similar issue. I've removed the program folders, shortcuts, registry entries, etc. but the programs still appear in the remove programs list under settings / system. Although it's not causing me any problems per se it is really annoying. If anyone knows how to fix it I'd love to know.
on pc's the list in add/remove
is
located in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
would asume that they are stored in reg on pda's too
I've had that happen a few times also, what usually fixed it besides manually deleting the folders and shortcuts, is to remove it in add/remove programs in activesync. Just check the box that says to delete from handheld and desktop.
I've tried that - using AS to remove the applications - but it still doesn't work. They all show up with a size of 0.0K but removing the tick in the box and selecting the remove from both device and computer option does nothing - they still show up in the list on both devices.
I have uninstalled programs and still have them in my add remove program list how do I remove them?
Is it in the registry i have tried everything and no luck thanks.
megs8888 said:
I have uninstalled programs and still have them in my add remove program list how do I remove them?
Is it in the registry i have tried everything and no luck thanks.
Click to expand...
Click to collapse
what program exactly, because I believe that some of them have this problem
programs
MAME CE3 and Concrete software bowling, i have uninstalled them no problem but it wont remove the from the add remove list and i dont know how to, thanks.
In similar cases, I use SKTools, an excellent program.
Here is the link http://s-k-tools.com/index.html?sktools/m_feat.html
I want to know why certain programs don't uninstall 100% even when it was installed and uninstalled correctly meaning the name still shows in the list as installed and there's no file traces left.
I have installed the SK Tools, but I cant seem to find how to do it, any instruction or fixes pls, thanks
In the registry, HKLM\Software\Apps if I remember well.
nope, apps still showing in "remove programs list" even though they were uninstalled like anything else
megs8888 said:
I have installed the SK Tools, but I cant seem to find how to do it, any instruction or fixes pls, thanks
Click to expand...
Click to collapse
Before starting, I would recommend a backup, just in case.
On the main SKT opening screen, go to
- left soft key "Category"
- select "Maintenance"
- select "Installed Programs"
- after a short search, SKT displays the list of all your installed apps
- when you point your stylus on the app you want to completely delete, you will see all its installed components in the lower half of the screen (a good thing at this point is to make a screen capture so in the worst case you can manually delete the remains, but normally it shouldn't be necessary, SKT usually doing a better removal job than the default remover)
- make sure that all boxes are unchecked, except the one you want to delete, and then go to left soft key "Action" and select "Uninstall marked".
I always just go into File Explorer/Windows/Start Menu/Programs
Then remove broken links from there.
He means removing the entries from the add/remove programs panel, not the start menu.
Tried this and no go any other ideas guys, the sk tools might be ok if i had programs installed, i might install them again and then uninstall via sktools see how that goes. any other ides.
sktools can remove it, but it is always on uninstall list!!
abc001 said:
sktools can remove it, but it is always on uninstall list!!
Click to expand...
Click to collapse
Reference link:http://answers.microsoft.com/en-us/...nstalled/7bad6dc7-d042-4bc2-8516-c9eeaeb5af58
I have found the solution to the various posts listed on not being able to get rid of an uninstalled prog in the remove progs window. Using MemMaid 2.3 go jump to/databases/database usage, highlight SwMgmtMetadataStore and click browse, highlight offending entry and delete it. Then do and soft reset and you will find that the prog is no longer in the remove prog window. Hope this helps.
In learning how to cook from the many good resources on this site I have read in several places that the contents of the mxip* provxml files will get re-written on every device boot. This means that some changes to the regsitry must be cooked in, or they will be lost on a reboot.
One such thread/post that details this is here.
Now the official thread from MSDN on these files is here, and it says this:
An Image Update Package can contain two types of provisioning files:
Cold boot files that will be processed by Configuration Manager only when the device is cold booted. The provisioning file name must have one of the following formats:
mxipcold_PACKAGENAME_*.provxml
or
mxip_PACKAGENAME_*.provxml
where PACKAGENAME is the name of Image Update package.
These files should contain settings that you intend to be applied only during cold boot.
Update files that will be processed by Configuration Manager both when the device is cold booted and, if their associated packages have been updated, during Image Update. The provisioning file name must have the following format:
mxipupdate_PACKAGENAME_*.provxml
All settings contained in these files will be re-applied whenever their associated packages are updated, regardless of whether they have or have not changed. Therefore, these files should only contain settings that you intend to be reapplied every time their packages are updated.
Microsoft recommends that you use a three-digit number in the name of your .provxml files in ROM, such as mxip_opr_100, mxip_opr_200, mxip_opr_300, so that there is an adequate number of ordinals to identify successive versions of the file.
Note Mobile Operators should avoid using provxml files to override (shadow) entries in Microsoft-owned provxml filesNote Mxip_*_*.provxml is imported only at cold boot when the device is initially configured. In effect, mxip_*_*.provxml and mxipcold_*_*.provxml are handled the same.Note Mxipupdate_*_*.provxml files are imported after cold boot and when the package containing them is updated.Now the reason I am posting is based on my experience and the underlined section above. This seems to state that a "cold boot" is equal to "when the device is initially configured."
What this means is that these mxip files DO get processed on a cold boot, but that a cold boot does not mean a reset/full-power off, but rather a CLEAR STORAGE.
My own tests show this to be the case. For instance, I have taken reg entries from several mxip, mxipupdate, and mxipcold PROVXML files which shipped with the latest AT&T stock ROM (decompiled with KaiserKitchen).
When I delete these values on my device THEY DO NOT COME BACK AFTER A REBOOT.
Based on these two facts it would seem to me that any statement which claims that these provxml files re-write the registry at every reboot is incorrect.
I would love for this to be corroborated by others or in fact, I would love to be proven this incorrect.
Not only do I want to know what it right...but I have a particular instance where a registry key is getting re-written at every boot. This value being overwritten is not defined in any XML, so my assumption is a DLL or other system service is resetting it. At this point, the particular value is not important to the discussion but if indeed there were a way to define in a provxml file a registry key which would be overwritten at reboot, that would be helpful.
Please advise!
thx
Anyone?
I'm looking for any proof that any xml files cooked into a ROM can reset registry entries on a standard reboot.
Cold-reboot = hard-reset, and as such yes all your provisioning files will re-run.
However it seems to me that the only thing which would re-apply a registry key would be a service/application/driver which is hard coded to do so and not anything specified in a provisioning file.
bengalih said:
Anyone?
I'm looking for any proof that any xml files cooked into a ROM can reset registry entries on a standard reboot.
Cold-reboot = hard-reset, and as such yes all your provisioning files will re-run.
However it seems to me that the only thing which would re-apply a registry key would be a service/application/driver which is hard coded to do so and not anything specified in a provisioning file.
Click to expand...
Click to collapse
If by "standard reboot" you mean soft reset then of course no settings are loaded into registry from any of your provisioning or other XMLs (unless you have some specifically set to be loaded at start up). The registry settings stay the same as you had them before soft reset.
But obviously they are read and loaded into reg after every hard reset, not only because autorun (customization) starts after hard reset - what does not happen after soft reset - but also because registry itself is recreated 'from scratch' after hard reset, *with* the settings from your XMLs (of course if there are pointers to them in your settings, otherwise even if they are there they will be 'excluded' or 'omitted' and become what I call "ghost files" - a files that don't do nothing but taking up space /edit: best example of XML "ghost file" is i.e. config.xml which didn't have its pointer in Config.txt thus all its registry settings were entirely omitted on every hard reset, as I saw in one of the ROMs).
You won't find "any proof that any xml files cooked into a ROM can reset registry entries on a standard reboot" because it is impossible (again - if by standard reboot you mean soft reset and not hard reset).
Thanks for your reply. What you are saying backs up what my beliefs are and my experience suggests. I don't want to call anyone out for providing false information (unintentionally I'm sure). But I have seen several posts by well regarded members that speak differently.
-888- said:
If by "standard reboot" you mean soft reset then of course no settings are loaded into registry from any of your provisioning or other XMLs (unless you have some specifically set to be loaded at start up). The registry settings stay the same as you had them before soft reset.
Click to expand...
Click to collapse
Again, I agree. However how do you explain this post and the others in the thread supporting the fact that a certain registry setting must be cooked in and will not survive a reboot?:
http://forum.xda-developers.com/showthread.php?p=2106160#post2106160
Also, what do you mean by "unless you have some specifically set to be loaded at start up"? How do you have a registry key specifically set to be loaded at start up? All regsitry keys are loaded at start-up (obviously). I pick out this comment because maybe this is the crux of the issue, if there is something I am unaware of. Are you saying there is a section in the registry that will automatically load certaind reg entries at boot (effectively overwriting them)? I would be unaware of anything like this, so please explain the statement.
-888- said:
But obviously they are read and loaded into reg after every hard reset, not only because autorun (customization) starts after hard reset - what does not happen after soft reset - but also because registry itself is recreated 'from scratch' after hard reset, *with* the settings from your XMLs (of course if there are pointers to them in your settings, otherwise even if they are there they will be 'excluded' or 'omitted' and become what I call "ghost files" - a files that don't do nothing but taking up space /edit: best example of XML "ghost file" is i.e. config.xml which didn't have its pointer in Config.txt thus all its registry settings were entirely omitted on every hard reset, as I saw in one of the ROMs).
Click to expand...
Click to collapse
I think this pretty accurate. However, I think technically the registry is created at cooking from the .REG files. The .REG files combine to make the .hv files, which are basically the flat file system that gets loaded to make the registry. The .XMLs which contain registry entries then get additionally loaded during customization, but the majority of the registry already exists in the .hv files. Would you agree?
-888- said:
You won't find "any proof that any xml files cooked into a ROM can reset registry entries on a standard reboot" because it is impossible (again - if by standard reboot you mean soft reset and not hard reset).
Click to expand...
Click to collapse
Right, ok, I am thinking as much. But still would like to understand why posts like the one I referenced claim that settings need to be cooked in or they will be lost on a reboot. These posts clearly seem to mean a standard-reboot, as a user who makes a regsitry change would obviously expect that change to be lost on a hard-reset. These posts definitly infer that the changes get lost on a "standard" reboot.
Cold Boot = Hard Reset or Clear Storage or Nand/OS Format (via Mtty/Ptty)
Provisioning xml's are most typically used by Operators to limit functionality, i.e AT&T uses them to disable the "Multiple Data Sessions Hack" by changing the AGPN RIL settings. These are used to overwrite certain registry settings established on boot before the OS even loads. Similarly, the standard provxml files do NOTHING, unless called for. This does not happen at a soft reset, only at hard reset & the difference is in the type of registry setting you are targeting. As stated before, some registry settings are loaded very early into the boot cycle, before the os even initializes, & are persistent so that they cannot be changed manually period. The RIL settings, used to enable the use of MediaNet & BBC concurrently are one such example. Provisioning Xml's only run when called for or when manually initiated with the use of a program capable of importing the xml's, such as SKTools.
There are indeed many setting that will revert when a soft reset is made.
bengalih said:
Again, I agree. However how do you explain this post and the others in the thread supporting the fact that a certain registry setting must be cooked in and will not survive a reboot?:
http://forum.xda-developers.com/showthread.php?p=2106160#post2106160
These posts clearly seem to mean a standard-reboot, as a user who makes a regsitry change would obviously expect that change to be lost on a hard-reset. These posts definitly infer that the changes get lost on a "standard" reboot.
Click to expand...
Click to collapse
i think these guys are gettin confused with reboots... maybe i'm wrong, but they also said that the hives get rebuilt on every reboot, i really doubt it...
agreed that provxml files only apply to a hard reset, but also did a little testing with that particular reg key... changed both values, reboot, activesync'd and surfed the net, reboot, same values, changed them back to original, reboot, everything sticks... i don't know what these guys are talking about, but it doesn't make any sense...
also, i can't find those settings in the stock att provxml files in OperatorPKG...
Thanks for replying GSLEON3. I understand everything you are saying about PROVXMLs, and I think we are on the same page, but I am still confused about some things you are saying...
For example in your post about the AGPSNVSetting. You state that you need to change it in the PROVXML file. You also state:
THIS HAS TO BE COOKED IN, REG EDITS AFTER INSTALLING WILL NOT STICK
Click to expand...
Click to collapse
My question is, what do you mean by it won't stick? If I go in with a registry editor after I have flashed the ROM and try to change it from 6 to 5. What happens? Either:
A) When I reboot the value will revert back to 6.
B) The value will remain at the 5 I set it to, but it won't actually work.
If the answer is A, then I ask how? How does it get set back to 6 if we established that the PROVXML files only get run during a cold boot/reset?
If the answer is B, then i ask how? A reg entry is a reg entry is a reg entry. If the value is set to 5, then whatever service reads that value should be seeing a 5. It shouldn't matter if that value was originally 6, as long as it is now 5 (and remains that way after a reboot).
This also leads into the comment you just made:
some registry settings are loaded very early into the boot cycle, before the os even initializes, & are persistent so that they cannot be changed manually period
Click to expand...
Click to collapse
I don't know if I totally agree with that. I think it depends when the OS loads. I would think that since all your registry entries are stored in the .hv file on your device that the OS needs to load first in order to initizlize the drivers to read that .hv file and mount it to the registry. That might just be nit-picky if you mean before you get the higher leverl drivers and GUI initialized.
But, the question still is what makes them "persistent so that they cannot be changed"?
In summary, a provxml only writes a reg entry ONCE, on cold boot/reset. This value appears in my experiments to be able to be changed afterwards and sticks (meaning it stays the same value after a normal reboot). Why then would a registry entry need cooking in instead of just a manual change afterwards?
I am not trying to argue here, OR prove you wrong.. I am just really trying to understand why you state what you do.
Thanks!
If you change the registry and then soft reset via pressing the reset button within a few seconds upto even a couple minutes then your edit is lost, as the registry is cached in ram and only written out after a bit...
You can get an edit to "stick" by
doing the change, then wait a bit, then power off, then power on, then wait a bit, then soft reset. All the above it to convince WinMO to flush the cache.
Or use any software-based soft reset (those let the OS know its resetting, so it flushes the reg cache.
Either that, or there is something running in the background resetting registry entries. HTC_Guardian, for example, is/was an app used to reset connection settings, at least under sprint. That evil thing slammed the "correct" values into the registry every 5 minutes or so... what a waste.
In either case, the proxml things only run on a hard reset/first boot init.
schettj said:
If you change the registry and then soft reset via pressing the reset button within a few seconds upto even a couple minutes then your edit is lost, as the registry is cached in ram and only written out after a bit...
Click to expand...
Click to collapse
Thanks for the feedback. I don't buy that however (at least not on the Kaiser). I can make a regsitry change with say, PHM and the split-second after I make that change I push in the reset button... that change is kept.
If it does that for one reg entry, it should do that for all. I don't believe that some entries get cached like that and other don't
schettj said:
Either that, or there is something running in the background resetting registry entries. HTC_Guardian, for example, is/was an app used to reset connection settings, at least under sprint. That evil thing slammed the "correct" values into the registry every 5 minutes or so... what a waste.
Click to expand...
Click to collapse
See, I think you are correct here. I believe that in all the cases where I have seen a registry entry get reset on a reboot is because a driver is hard coded to reset it at boot time. On the latest AT&T release for instance if you change the LockLevel for backlight it is always reset to 0 after a reboot. There is no reference to this registry value in the rgu's or provxmls in the decompiled ROM.
schettj said:
In either case, the proxml things only run on a hard reset/first boot init.
Click to expand...
Click to collapse
agreed
bengalih said:
Thanks for the feedback. I don't buy that however (at least not on the Kaiser). I can make a regsitry change with say, PHM and the split-second after I make that change I push in the reset button... that change is kept.
Click to expand...
Click to collapse
You don't have to believe it, but i know this can be true. I can't speak to the cause, but i know that often times i must make my entry and then exit the program before i soft reset or my settings will not be kept. Also, I have experience many times where i will make a registry edit, and if i do not soft reset before doing anything else then my edit does not take effect. For example, i'll reply to a sms before soft resetting and my entries won't take effect. For this to be true then the original entries must be stored somewhere, at least temporarily. It certainly could depend on the software used though, and may have nothing to do with the rom. As i said, i can't speak to the reasons why this would occur as well as man others, but i can state my experiences through making thousands of registry changes.
I just tested this. 5 times, 5 different registy entries using PHM Reg Editor with both the stock AT&T and HTC 6.1 ROMs.
Each time I made a change, I pushed my stylus into the reset button immediately after clicking on OK to the change.
In every case, my registry entry remained the way I changed it to prior to boot.
I would be interested if you could recreate results to the contrary and if so what ROM and registry editor you are using.
scotchua said:
You don't have to believe it, but i know this can be true. I can't speak to the cause, but i know that often times i must make my entry and then exit the program before i soft reset or my settings will not be kept. Also, I have experience many times where i will make a registry edit, and if i do not soft reset before doing anything else then my edit does not take effect. For example, i'll reply to a sms before soft resetting and my entries won't take effect. For this to be true then the original entries must be stored somewhere, at least temporarily. It certainly could depend on the software used though, and may have nothing to do with the rom. As i said, i can't speak to the reasons why this would occur as well as man others, but i can state my experiences through making thousands of registry changes.
Click to expand...
Click to collapse
Hard reset, softt reset, rom update, cold boot, warm boot, clear boot,image update...
Hello
I found some usefull links.
The well-known articles about mixp, mixpudate and mixpcold...:
msdn.microsoft.com/en-us/library/ms889522.aspx
msdn.microsoft.com/en-us/library/bb737254.aspx
Definitions of Power States Transitions
msdn.microsoft.com/en-us/library/aa450592.aspx
Definitios of "clean/cold/warm booting" and their issues:
msdn.microsoft.com/en-us/library/ee490762.aspx
Terms of "Image Update"
msdn.microsoft.com/en-us/library/bb737478.aspx
msdn.microsoft.com/en-us/library/bb737638.aspx
I think that a Soft-reset is like a warm-boot, a Hard-reset is like a clean-boot and you only have to remove all de batteries (all power off) to get a cold-boot. I now understand why some fellows tells to me to remove the battery two minutes .
So
remove the battery or exhausted -> cold boot -> mixp & mixpcold & mixpupdate
hard-reset -> clear boot -> mixp & mixpcold & mixpudate
soft-reset -> warm-boot -> no mixp*
rom update -> image-update of all parts of the rom -> mixp & mixpcold & mixpudate
So normally, every time that you change the rom or order a hard-reset you mobile should execute all mixp*
From time to time something goes wrong when processing mixps during the fisrt boot after a rom-update and then you need to order a hard-reset to execute all mixp*again. I suspect that this happens when hard-spl does not force a cold-boot after the rom-update process and a warm-boot happens.
Finally
File System Boot Process. Describe which and when the actions happens:
msdn.microsoft.com/en-us/library/ee490357.aspx
Best regards.
I know this reply is seriously late in coming, but I was working thru a few registry issues and fixing a few chef cooked roms and this thread popped up.
Maybe it'll help someone in the future, trying to understand this dying architecture. (Curse you M$)
What you are failing to see, is that there are several ways that provisioning xml's can be delivered. Via cab files, straight provxml file or even xml's called on startup, not justat cold/hot boot.
AT&T as well as other OEM's used to have a bad habit of SHADOWING MS or HTC registry settings (Overwritting reg values thru use of xml provisioning). AT&T would call for their OEM Network Provisioning xml to silently install at every reset, much like a 2577 cab file. The OEM can also use the OAL (OEM Adaptation Layer) to overide or change settings in the registry, even thru the use of provisioning xmls.
The old AT&T APN provisioning via cab file we saw in Kaiser & first TP rom is a very good example of bad practices with regards to xml usage.
You can also set certain reg keys to be persistent. Try deleting the "Windows Default" (CHome) today registry key. without negating the setting with a nocharacteristic xml setting or a reg such as [-hklm/current user/etc...] this key will be persitent and also cannot be deleted.
Provxml's are good for moving things & certain settings, however, I have come to believe that registry optimization is a key component in device performance & with the new HV editing tools, you are better off adding entries directly to the hive & keeping the windows directory clean & light.
I wish only more chef's would utiolize these new tools & features. Have you ever gone thru a cooked rom registry & found all of the hanging & invalid registry keys?
The common cooked rom, even from the bvest cooks at XDA, usually have anywhere from 12% to 24% of empty or invalid registry settings. On top of that, you can have upwards of 12% - 18% invalid system type registry settings & then another 24% - 28% invalid user type registry settings.
The average cooked rom has a reg size of 811088. This number when optimized with proper settings & true removal of defunct values/keys would be more in the 647000 size range. That is common for a good chef, now imagine the guy using the standard rom kitchen based on a straight OEM rom. Cooks forget that registry values come from xml's, cab's, registry hives, even some executables. Setting are often duplicated between packages and hive and OEM provisioning files. This means that just because you remove a package from your kitchen does NOT mean that all the related registry data for that package will also be removed. For this you really need to modify the hives manually with the new HV editing tools, or completely rebuild the hives using a newer kitchen like OS Builder that allows you to build HV files from scratch. even then I recommend usign HV editing tools to confirm nothing is left behind unintentionally.
An optimized registry absolutely means increased performance.
Hello everyone,
I was using SKTools in my old Diamond, and I was generally happy with it. As a result, I installed the app in my brand new D2, and started using it there as well.
Unfortunately, the results were a nasty surprise: When I ran the "Clean" routine, (in which I had also enabled the "Invalid Registry Values" setting, which is set to "not used" by default), I realised that the shortcuts for the default programs in the TF3D Start Menu (i.e. Home, Profile, Calendar, Settings) had disappeared for good. Since these 4 programs are unmovable from this screen, I couldn't even replace them with something else... The solution? Hard reset...
The D2 now works like a breeze, and for this reason I am afraid to run SKTools Clean again, even with the "Invalid Registry Values" setting disabled. I am also reluctant to use even the SKTools Backup module, although I definitely need to have a backup of my phone.
Has anybody used SKTools Clean and/or backup in D2? Does it work properly? Should I try it?
Thanks
Sprite backup worked great for me, after a hard reset and restore my phone worked as it did when I made the backup.
You should contact sktools manufacturer about these issues. They have the best answers
darfri said:
You should contact sktools manufacturer about these issues. They have the best answers
Click to expand...
Click to collapse
You have a point, yet SKTools will not tell me which piece of software to use for backup if their own one doesn't do the trick... Nor will they direct me to another piece of software for "cleaning" the device, if theirs is prone to problems.
This is why I am asking feedback from you people here; to tell me if you have tried the SKTools app, and in case it didn't work out, which pieces software you would advise for these jobs (cleaning + backup).
jcan said:
Hello everyone,
I was using SKTools in my old Diamond, and I was generally happy with it. As a result, I installed the app in my brand new D2, and started using it there as well.
Unfortunately, the results were a nasty surprise: When I ran the "Clean" routine, (in which I had also enabled the "Invalid Registry Values" setting, which is set to "not used" by default), I realised that the shortcuts for the default programs in the TF3D Start Menu (i.e. Home, Profile, Calendar, Settings) had disappeared for good. Since these 4 programs are unmovable from this screen, I couldn't even replace them with something else... The solution? Hard reset...
The D2 now works like a breeze, and for this reason I am afraid to run SKTools Clean again, even with the "Invalid Registry Values" setting disabled. I am also reluctant to use even the SKTools Backup module, although I definitely need to have a backup of my phone.
Has anybody used SKTools Clean and/or backup in D2? Does it work properly? Should I try it?
Thanks
Click to expand...
Click to collapse
I guess following registry values was deleted by using the Clean! action :
HKEY_LOCAL_MACHINE\Software\HTC\Manila\ProgramLauncher\3\IconPath
HKEY_LOCAL_MACHINE\Software\HTC\Manila\ProgramLauncher\0\IconPath
SKTools will make a backup (standard setting) for the deleted Registryvalue.
Take a look into " My Documents\Registrybkp " folder.
If following files exist:
\My Documents\Registrybkp\Software_HTC_Manila_ProgramL auncher_3_IconPath.rgb
\My Documents\Registrybkp\Software_HTC_Manila_ProgramL auncher_0_IconPath.rgb
then start the option " SKTools Backup " and mark these 2 files and make a restore.
Exit SKTools
Softreset
To prevent the deletion by using Clean! action, go into settings > Invalid Registry Values > Exclude filter
Tap on Exclude filter and enter (field on the top) : Manila\ProgramLauncher;
OK
CharlyV said:
I guess following registry values was deleted by using the Clean! action :
HKEY_LOCAL_MACHINE\Software\HTC\Manila\ProgramLauncher\3\IconPath
HKEY_LOCAL_MACHINE\Software\HTC\Manila\ProgramLauncher\0\IconPath
SKTools will make a backup (standard setting) for the deleted Registryvalue.
Take a look into " My Documents\Registrybkp " folder.
If following files exist:
\My Documents\Registrybkp\Software_HTC_Manila_ProgramL auncher_3_IconPath.rgb
\My Documents\Registrybkp\Software_HTC_Manila_ProgramL auncher_0_IconPath.rgb
then start the option " SKTools Backup " and mark these 2 files and make a restore.
Exit SKTools
Softreset
To prevent the deletion by using Clean! action, go into settings > Invalid Registry Values > Exclude filter
Tap on Exclude filter and enter (field on the top) : Manila\ProgramLauncher;
OK
Click to expand...
Click to collapse
That was very helpful! Thanks!
In the next version we will exclude these registry values.
At moment, you can do by hand (see my previous post).