• Content count

  • Joined

  • Last visited

  • Days Won


GrofLuigi last won the day on September 20 2014

GrofLuigi had the most liked content!

Community Reputation

11 Good

About GrofLuigi

  • Rank
    GroupPolicy Tattoo Artist
  • Birthday

Contact Methods

  • Website URL

Profile Information

  • OS
    none specified
  • Country
  1. Usually it's hiding in UPPERFILTERS or LOWERFILTERS of other devices. Delete ASATAFLT from there. I take a strong hint from the FLT in the name (filter). Also, try searching for ASATAFLT in the registry and track down everything related to it (for example guids or other long strings - search for them; then for anything related to them and so on; taking care you don't delete something you'd need). GL
  2. Find msinfo32.in_ in your source, expand it (I use Universal Extractor, it is also possible with command line) and you'll see what is needed. It's quite simple. I think (I'm not sure) you can right click it and install it. You'd need to provide MSINFO32.EX_ too (whether expanded or not, I don't know). It is located at the same place as MSINFO32.IN_. I don't see other files mentioned in the .inf file, but there are some with similar names (.dll). Maybe you'd need to provide them as well, or they are already present in \windows\system32 (Nlite doesn't remove them?). Another way would be to put expanded MSINFO32.EXE directly into \windows\system32 and hope for the best. Maybe try regsvr32 msinfo32.exe in the command line (and also provide the .dll if it isn't already present and try that line on it too). I'm not on XP right now, but looking at my preset I can't see it (but then, I didn't remove it there). I think it was called "System Information" or something. GL
  3. Task scheduler? (I don't know enough about it to give a proper example.)
  4. No, MsiInstaller is a different thing, an EventLog source. It's not an "entity" in the security sense to give it permissions. So it's case #2, broken installer that breaks the registry. In any case, I doubt you should run the installer from that location (Program Files), unless you are trying to uninstall it (which I strongly suggest you try, because I think nobody needs that). I can't do quotes in this editor properly, so I'll just try to paste, if that works: Things like Windows Desktop Search integration, the OneNote Printer Driver, Primary Interop Assemblies (PIAs), and Visual Studio Tools for Office (VSTO) are things no normal user should ever need. They are bloat aimed to drag you into Microsoft dependency, which would be the case if they were slightly useful, which they are not. It's another thing if Office doesn't work without them (as I read that version 15 breaks 32-bit Office if uninstalled), but there is some chance it won't break. You could (have) tested this if you tried to run your Office programs after uninstalling it, but before reinstalling it. But it's not too late to try again. Better way would be to use Add/remove programs and uninstall only the Extensibility Component, or use Nirsoft's MyUninstaller to find it among all possible entries. Otherwise, the way to fix it is to make a bug report to Microsoft or edit the .msi with Orca or similar tool, both tedious tasks. GL
  5. I wouldn't bother if I were you, except if you have extreme case of OCD and want to satisfy it. I am prety sure everything works even now (without the "fixes"), except 0.01% of chance that ink/handwriting component won't. I give it such a small chance because the keys are still present and if needed Word (or any office program) could invoke the component (call it). What is potentially broken is some parts of them, or registry values, that couldn't possibly be so important. The registry values are part of COM registration (mostly used in inter-process communication), and because the main keys are present, I think it will still manage to call them just fine. That's if you ever use ink/handwriting. Edit: the forum editor wouldn't acknoledge ENTER, even for a single newline, so I tried some key combinations and CTRL+ENTER posted the unfinished text. Now where was I... "Will Repair... create different keys and so progress will be lost?" (I'm re-typing this because copy+paste also doesn't work) - Well, it depends. Obviously, the installer script is broken, but is it broken in such a way that it has unrealistic expectations (that the keys are unprotected) or it breaks them itself? I don't know, but if you insist on Repair Install, I think it could make no additional harm, except possibly the need of "de-protecting" them again later. I think repair install has a better chance than uninstall+reinstall, and is less work anyway.
  6. I don't think WRP is protecting registry keys, but I am not sure. I haven't seen it in action because I usually apply many tweaks at the same time aimed to "tame down" the system, so I am not sure if any of them is preventing that. At the same time, I often go nuclear on my systems and apply blanket full permissions to myself (or Administrators group, to be exact) and SYSTEM to whole branches of registry. Sometimes it bites me back and some (many) things break, so I don't recommend you do that. What I think you should do is this: > Should I ALSO give "Administrators" Full Control permission? YES. I think that might help you, if you don't mind editing 60+ permissions. And I returned and read this topic from the start, and now I think you shouldn't bother much about this, ink/ink divider/ink whatever is office component for tablet mode / handwriting recognition, not important at all. I suspect most other keys with errors are related to it too, the CLSID and INTERFACE registration of the "ink" components. "Ink" has steadily progressed through Microsoft OSes to be more and more important (for them). It wasn't present in XP, only installed with Office 2003, then it became system component with many CLSIDs and other registration components in 7 (or maybe Vista, I'm not sure) and increasing its presence in later OSes. I suspect Office 365 is expecting (being programmed to expect) Win8.1 or Win10, where "Ink" is even more prominent and is not prepared for what it sees on Win7. Just a wild guess. Whatever the reason, I am almost sure you wil not encounter any problems even if "ink" is not working, and additionally I'm pretty sure "Ink" will still work even with these errors anyway. GL
  7. That TIdo.cmd is as powerful as it gets. I've done all kinds of mischief with it. The output of Whoami is not what it seems to be. It either lies (not accounting for the rights of the parent group, which apply to the current user), or the disabled/enabled state is not what we think it is: And, as far as I know (at least until previous versions of Office) OSSP doesn't protect anything else besides Microsoft's profit, in the sense that it bans you from running unlicenced versions of Office, but doesn't actively protect any resources, including registry keys. I repeat, AFAIK. GL
  8. Without knowing much about this particular situation, I'd expect the cause of two SYSTEMs being present would be THE SCOPE to which these sets of permissions apply. In other words, look in the field Apply to. One SYSTEM may apply to "This key and subkeys", and the other to "This key only" or "Subkeys only" (or any combination of these three). The most comprehensive, i.e. the one you'd usually want is the first one, "This key and subkeys". After Vista, there have been many "boobytraps" in the registry where some subkeys don't inherit permissions from the parent, for no obvious reason, and could not be changed "top down", you'd need to dive down to the lowest branch and change them there first. And often work your way up. GL
  9. sc delete ISMPUSBFilter and search for ISMPUSBFilter in registry and delete accordingly (usually everything).
  10. Well, it seems that whoami /priv doesn't tell the whole truth, it disregards the privileges that are part of the group (administrators) and are in fact enabled for the account. Out of the three PowerShell scripts I found, two were intended for processes, and the third one requires newer version of PowerShell than the one that is in Win7 SP1, so I'm putting that on hold for now. I've turned my attention fully to good old ntrights, but how to check the privileges if whoami is inaccurate? Well, in the same Resource tools kit for Server2003 there is showpriv.exe. I've parsed the output of both to textfile, sorted it and deleted the crud, so I'm left with the list of privileges. Now only to compare. But no two lists are the same (including whoami's and the output of accesschk.exe), and I've also read that ntrights has some undocumented privileges, so everything needs to be tripple-checked. So far, it doesn't seem promising, at least for the Administrator account (yeah, I've been using that one since day one of Windows install ), there isn't much left to do. * After several edits: the forum editor is disastrous, it is impossible to bold something (I've done it manually), and paste doesn't paste at the cursor position.
  11. *Edit: I'm moviing the text to the top because the stupid forum software ate it after the table. While I remember on XP/Win2003 most of them were enabled and there was a slight benefit enabling those that weren't (granting lock pages in memory right or debugprivilege)... I forgot most of it already. Of course I'll try enabling most of them, if not all, because I hate artificial restrictions Microsoft is putting to restrict the way how I use my computer, even if I won't see any benefit. The real question is: Will it break something? Common sense says it shouldn't, but I wouldn't be surprised if Microsoft has put artificial blockades just to make our life miserable. While I'm at it, I might grant system/trusted installer some more rights if they lack some, because I'm generous. I have armed myself with NTrights (reports say it still works on Win7 x64), as well as with few powershell scripts... Wish me luck. The output of whoami /priv: PRIVILEGES INFORMATION ---------------------- Privilege Name Description State =============================== ========================================= ======== SeAssignPrimaryTokenPrivilege Replace a process level token Disabled SeLockMemoryPrivilege Lock pages in memory Disabled SeIncreaseQuotaPrivilege Adjust memory quotas for a process Disabled SeSecurityPrivilege Manage auditing and security log Disabled SeTakeOwnershipPrivilege Take ownership of files or other objects Disabled SeLoadDriverPrivilege Load and unload device drivers Disabled SeSystemProfilePrivilege Profile system performance Disabled SeSystemtimePrivilege Change the system time Disabled SeProfileSingleProcessPrivilege Profile single process Disabled SeIncreaseBasePriorityPrivilege Increase scheduling priority Disabled SeCreatePagefilePrivilege Create a pagefile Disabled SeBackupPrivilege Back up files and directories Disabled SeRestorePrivilege Restore files and directories Disabled SeShutdownPrivilege Shut down the system Disabled SeDebugPrivilege Debug programs Disabled SeSystemEnvironmentPrivilege Modify firmware environment values Disabled SeChangeNotifyPrivilege Bypass traverse checking Enabled SeRemoteShutdownPrivilege Force shutdown from a remote system Disabled SeUndockPrivilege Remove computer from docking station Disabled SeManageVolumePrivilege Perform volume maintenance tasks Disabled SeImpersonatePrivilege Impersonate a client after authentication Enabled SeCreateGlobalPrivilege Create global objects Enabled SeIncreaseWorkingSetPrivilege Increase a process working set Disabled SeTimeZonePrivilege Change the time zone Disabled SeCreateSymbolicLinkPrivilege Create symbolic links Disabled
  12. Last version of Sysinternals' Process Monitor that works on XP is 3.2. For now, it can be downloaded from the link, other snapshots of that page throw an error on the .zip file. GL
  13. Well, when you put it this way, one might think that Microsoft is in the business of selling bells and whistles . And I agree fully with that. GL
  14. They are the same. The difference might not be in that location anyway, it might be in ENUM, but are you sure it isn't a hardware failure? GL
  15. How about this?