@Petar, thank you. I still have the problem. Then I guess I should repatch the whole things again? Dang, my torrent won't even reach my capped DL (90KB/s) :/
@Efendy, sorry but I cant give any more assistance, becuse I'm curently running on 32bit system I'm planing to switch to 64bit but I hope till then you will sort the problem out...
So those with the user32.dll.mui problem, do you use the MUI language pack, as Gyrxiur just mentioned above? We've been looking for another variable, and this may well be it.
I give up, lol! I even installed a new copy of Vista into VMware to test, and the user32.dll.mui and the batch file I made for it worked fine even after rebooting it a few times, so I have no idea ... I guess I should have said that the batch file I made is for en-US + SP1 + x64. I assume you've got all those going for you? There must be some other variables that I'm not seeing
There must be. And is this just a 64-bit issue? That is, after accounting for user error, has anyone seen 32-bit behave this possessed? Further thought: While I realize it's not necessary on those systems in which there isn't a problem, I wonder if overwriting the files from completely out of Vista would help? And by that, I don't mean from the recovery console either (Vista is sort of still running in that state) but from either a bootable CD (e.g. Active Bootdisk) or another OS on a multiboot system. Also: Process Explorer allows you to search on filenames. If you search on this filename, it'll show you every program that's associated with the file currently as well as the paths of the file. Anything interesting there on non-working systems?
Yes, well, I guess that's another dead end, unless someone with a working system sees something different.
Can we go as far as saying: If explorer.exe is in the list you will not have the problem, and if it isn't you will? We need more testing to see if that's the case (it is also true on one working 32-bit system I checked), but since explorer.exe (the shell) is fundamental to the interface, I bet it's fairly reasonable to assume. The theory is that if, for Mystery Reason X, explorer.exe is not able to latch on to the real user32.dll.mui, that it goes to some kind of "default" test mode invariably--and it always shows the watermark. Grasping mode: file permissions?
But ... but ... if Explorer isn't hooking into the user32.dll.mui, how does it know to say "Test Mode" and not "Jibber Jabber"? I would have guessed in that situation that Explorer would refuse to load or even BSOD.
I think we have to trust that it's not, since how could it be otherwise missing from PE? So given that it's not and that Vista does know which mode that it's in (from the bcdedit command), it looks like it's hard-wired. How could it not be considering that all user32.dll.mui's are edited? Vista is capable of ignoring it for whatever reason, and PE seems to be revealing this. It would be interesting to reverse steps: take it out of signing mode and replace the original tcpip.sys and user32.dll.mui. Does PE then show user32.dll.mui related to explorer.exe?
For those with Vista Ultimate install, use Dreamscene backgrounds to clear "Test mode" is better looking as well as simpler.
haha... you are right beray. I had dreamscene on since yesterday, but i didn't notice that the test mode was gone...
Message to till69: I did everything you posted few sites before, hexed the file properly (double checked), then signed it and putted in a place of original one in C:\Windows\System32\drivers directory (in safe mode), the TESTSIGNING option is enabled. I've restarted my OS, and everything seems to be ok, because i'm seeing Test Mode on my desktop, but when i start uTorrent, my web sites stops working immediately. What am I doing wrong? It should work, but it's not...