kelaniz

Intellitype 5.5 won't work calling the MSI without editing it. You have to run the oemsetup.exe ((in the package) to call the oemsetup.ini file like this: Oemsetup.exe oemsetup.ini My oemsetup.ini is: [KEYBOARD] LANGUAGE=1033 DEVICE=WCK SHORTCUTS=0 There's info in the help file on how to set it up for your particular model. Also, there's an OEMkeys.exe / oemkeys.ini where you can setup your favorites keys. This installer is a major pain, but once you figure out the oemsetup.lini, it's simple. Kel

When you connected each mouse one at a time to the PS/2 port, did you do it while windows was running, or did you plug it in, boot, and then saw it didn't work?

jaclaz: Thanks for the HDhacker link. I've been searching forever for a utility like this that wasn't part of a 500MB suite. Kel

Are you running any of these programs? C:\WINDOWS\system32\ZoneLabs\vsmon.exe C:\WINDOWS\system32\svchost.exe C:\Program Files\Musicmatch\Musicmatch Jukebox\MMDiag.exe C:\Program Files\Musicmatch\Musicmatch Jukebox\mim.exe C:\Program Files\utorrent.exe C:\Program Files\MSN Messenger\msnmsgr.exe C:\Program Files\HJT\HijackThis.exe I found a cached question on a Spanish spyware board asking about a similar log entry. I couldn't find an answer, but it seemed to be either one of the above apps, or possibly some form of spyware. Have you scanned for any recently? Kel

FYI, and for the record, 52 is valid as well, but it is ususally a CP/M one: http://www.win.tue.nl/~aeb/partitions/partition_types-1.html Ah, thanks for the correction! The text list I use is pretty old. When I last checked, 52 wasn't listed in either. But then again, it wasn't in Paragon Partition Manager, so I don't feel so bad. Hehe. Yay for 42! On this box, though. It was definitely 52. After similar crashes, I've seen partition IDs become: 52, 97, 00, 06, 69, ?1, even high ASCII characters . Never seen a 42 though. If my disk ever did that, I think I'd take it as a sign, and do a quick world-news check for recent apocalyptic signs 95% of the time I've dealt with this, the system didn't use dynamic disks. A few times, the system wasn't even running Windows. Still, it does seem to happen more frequently on Winboxes. The problem seems to appear when a disk-intensive application (Azureus downloading a 4GB linux distro) malfunctions and takes down the OS with it, leaving the entire box unresponsive, but not completely crashed. It's either due to that app's dying gasps, or that second of chaos (after you stop cursing) when you finally pull the plug, the boot sector, partition ID, and usually the backups get corrupted in some way. I can see it happening like this. An app is happily writing huge chunks of data to disk when it partially crashes abut completely takes down the OS. Parts of that app are still running in limbo, as the OS support has been essentially pulled out from under it. In that Azureus case, the user saw the network connections remained open and it was still writing data to disk, so she left it alone for an hour to finish. I'd imagine that with both the app and the OS now unstable, OS-based disk write protection might not work so well, if it worked at all. Now, I don't know if the above is even remotely close to what actually happens, or if it's even the cause. But in most of the cases I've dealt with, users with the invalid partition ID reported similar scenarios so darn frequently, I started to notice the pattern. Kel

Oh duh. Load hive. I knew that. I'll play with the Default.dat and see what fun develops. Interesting thing, 8 hours after my last post, I checked the VM and the sysvars worked again! Yes, the same ones that supposedly couldn't work. No idea why. Still, to be on the safe side, I took all the CU*, FAVS, QL sysvars and made them user vars. One oddity I noticed... Before adding the user vars, I removed all vars in HKCU\Environment and rebooted. Then I added the variables via the control panel - System applet and used the same built-in variables (%appdata% - %userprofile%) like before. Interestingly, half the variables appeared in the registry as type REG_EXPAND_SZ, and preserved the unexpanded variable. The other half, using the same variable didn't. I entered: Name:CUSM Value:%UserProfile%\Start Menu Name:CUSMP Value:%UserProfile%\Start Menu\Programs And they appeared in the registry as: CUSM REG_EXPAND_SZ %UserProfile%\Start Menu CUSMP REG_SZ C:\Profiles\Kelani\Start Menu\Programs It's no problem, as both work fine. So, I manually imported the REG_SZ ones as REG_EXPAND_SZ with the appropriate data. Those also work fine. So, apparently you can preserve unexpanded strings in permanent user variables. Of course, if my recent history is any indication, that might also stop working any day now If so, I'll fall back on the autoexec.bat method, which has always been my last resort. Man, this incident was incredibly weird. That's from a guy who's been explaining Windows behavior to people for 14 years. If I wasn't absolutely sure both boxes were virii/malware free, I'd swear they were infected with something. Thanks again to Yzow, Memnoch and (once again) deXter for this week's help. I'll probably return next week with yet another obscure question like... "What causes Windows Picture resizer powertoy to fail with "Unable to resize Foo.jpg", or something. Thanks guys, Kel

Still confused. Big surprise. Let me clarify: the %QL% variable DID work when set in a batch file, and I'm pretty sure it worked as a system variable until yesterday. Does it being set in a batch file make any difference? My previously-mentioned post-setup batch file deletes and copies ~20 shortcuts to and from Quick Launch. Every command uses %QL%. This worked perfectly for the past 6 months I've been testing that XP build. Before I add any command I'm unsure about to that file, I test it at a command line to verify it works. If it doesn't, I don't add it until I find a way where it works. Example from monster Kel LinkManager.cmd: SET QL=%appdata%\Microsoft\Internet Explorer\Quick Launch ECHO Copying Firefox Shortcut to QuickLaunch COPY "%AUDT%\Mozilla Firefox.lnk" "%QL%\" Next, my new twin cat-owning avatar bro deXter said: That makes perfect sense. Say I set the following system variable via control panel or registry: Key=HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment Value=MEOW Type=REG_EXPAND_SZ Data=%userprofile%\desktop If I understood you correctly, Before login, MEOW will point to some variant of %SYSTEMROOT%\system32\config\systemprofile\desktop After login, it should become MEOW=%SYSTEMROOT%\Documents and Settings\Kelani\Desktop Is that right? That may be the root of the problem. I don't think this change in mapping is happening anymore, if it ever did to begin with. When I started noticing the CU* system vars pointing to systemprofile I *was* logged in. Not sure if it's relevant, but I don't use the welcome/login screen. Since both boxes are single-user, they both auto-login. I'm never logged out of the box. Now mentally, that's a whole different story. Anyway, here's an abbreviated list of my original system variables when I noticed the problem. I've since removed the CU*, QL and FAVS vars from my registry, since they don't work anymore (and to prevent even more confusion). I left the AU* ones, because they DO work and still point to the correct path. Those are OK. AUDT=C:\Documents and Settings\All Users.WINDOWS\Desktop (EXP_SZ %AllUsersProfile%\Desktop) AUSM=C:\Documents and Settings\All Users.WINDOWS\Start Menu (EXP_SZ %AllUsersProfile%\Start Menu) AUSMP=C:\Documents and Settings\All Users.WINDOWS\Start Menu\Programs (EXP_SZ %AllUsersProfile%\Start Menu\Programs) CUDT=C:\WINDOWS\system32\config\systemprofile\Desktop (EXP_SZ %UserProfile%\Desktop) CUSM=C:\WINDOWS\system32\config\systemprofile\Start Menu (EXP_SZ %UserProfile%\Start Menu) CUSMP=C:\WINDOWS\system32\config\systemprofile\Start Menu\Programs (EXP_SZ %UserProfile%\Start Menu\Programs) DEVMGR_SHOW_DETAILS=☺(Shows a Smiley now?! dword says 1. That's new.) FAVS=C:\WINDOWS\system32\config\systemprofile\Favorites (EXP_SZ %userprofile%\Favorites) COMPUTERNAME=CRASH (appropriate, ain't it?) CLIENTNAME=Console SESSIONNAME=Console USERNAME=Kelani HOMEDRIVE=C: SystemDrive=C: SystemRoot=C:\WINDOWS ProgramFiles=C:\Program Files HOMEPATH=\Documents and Settings\Kelani USERPROFILE=C:\Documents and Settings\Kelani ALLUSERSPROFILE=C:\Documents and Settings\All Users.WINDOWS APPDATA=C:\Documents and Settings\Kelani\Application Data Example of what I see: CUDT points to systemprofile, AUDT points to correct location. C:\>cd /d %userprofile%\desktop <--- Testing where %userprofile%\desktop sends me, C:\Documents and Settings\Kelani\Desktop>cd /d %CUDT% <--Same command as the above, just as a variable C:\WINDOWS\system32\config\systemprofile\Desktop> <--Sends me to the **** System Profile C:\>cd /d %AUDT% <--Same command as %CUDT% but replace AllUsersProfile instead of UserProfile C:\Documents and Settings\All Users.WINDOWS\Desktop> <--Sends me to the correct path. From deXter's post, I could see why the AU* variables will work, but the CU* vars don't. Maybe they would work again if they weren't still pointing to the **** systemprofile after I login. I dunno. Why they doing that now is what I don't get. I'm pretty sure that's why %QL% fails, as there's no Quick Launch dir in systemprofile\Application Data\Microsoft\Internet Explorer. But if I understood deXter right, it shouldn't be looking for it there anyway. As I said, for months, they worked fine. I don't know it that was due to being set in a batch file vs the registry, but one way or another, they worked. So any ideas on why they're pointing to system profile, or how to fix it? I did have the CU* vars in my RunOnce registry import, but the only entity referencing those variables is me via cmd files and a command line, I don't see how they're staying mapped to the systemprofile, and making it be' the user's profile, if that's what's actually happening. It just seems like having to set all these CU* variables as user vars negates most of the purpose of using variables in the first place. It doesn't help that the Userprofile and ProgramFiles dirs on OldBox and NewBox are different (Documents and Settings \ Profiles | Program Files \ Programs). That's actually why I created these vars to begin with: to simplify copying files & settings between the box and the new build. Using already-expanded variables would be a massive pain in the...text editor. nmX.Memnoch: How do you go about loading the Default User NTUSER.dat, anyway? Never heard of doing that before. Kel

The most common problem I've seen with corrupted/damaged partitions occurring in WinXP is simply a screwed up partition ID. Running a modified or bad install, using alpha/poorly written software that causes Windows to crash and reboot (without a blue screen) usually precipitates it. Windows seems fine until you reboot. Then you see you have a problem. You can use any recovery utility that lets you edit the partition ID. NTFS's ID is 07 (technically, 0x07) When you scan the partition with your app of choice, make sure that partition ID matches. Last time it happened to me, my install and data were all fine, but the partition ID had been changed to 52, which is not a valid filesystem ID. Change it back, and it works like a champ. If that doesn't work, your corruption may extend to the entire MBR or FAT. Then it gets a little more complicated to fix. Kel

Oh Dammit. Sorry Kel #1. please don't take my addons away. Blame the IETab Firefox extension. I entered MSFN through the front gate, and IETab gavve IE control. Then IE pulled its " I AM IE. I have made your Space key=ENTER and your Arrow keys now go Back 3 pages. YOU'LL LIKE IT!" crap. Please delete my grievous zombie post before Kel#1 really goes nuts. Kel#2

This is not my week. Ok, I have a few variables I've been using on my main box and have imported to the registry during setup on my custom build DVD. The system variables below are all basically abbreviations of a few windows locations I use: AUSM = %AllUsersProfile%\Start Menu AUSMP = %AllUsersProfile%\Start Menu\Programs AUDT = %AllUsersProfile%\Desktop CUSM = %UserProfile%\Start Menu CUSMP = %UserProfile%Start Menu\Programs CUDT = %UserProfile%\Desktop QL = %AppData%\Microsoft\Internet Explorer\Quick Launch FAVS = %UserProfile%\Favorites These are all system variables, with REG_EXP_SZ strings sitting happily in the correct registry location. Typing 'set' from a command line shows them as you see them here. I originally set these variables for a post-first-login Link Management CMD (moves all misplaced .lnk and .url files where I want them.) They vars ended up being so useful for command-line work and installs, I set them as system vars, and added them to the registry import on my test box VM. I've been using them without incident for several months, and they appeared to work flawlessly...Until an hour ago. The most annoying problem I'm having, is the %QL% variable, while defined, simply will not work anymore. Any time I try to copy/move anything, or cd there, I'm getting "the system cannot find the path specified" But if I cd to the actual path that's copied from the variable's 'set' response, it works just fine. Watch, I'll show you. C:\>cd /d %QL% The system cannot find the path specified. C:\>cd /d "%QL%" The system cannot find the path specified. C:\>cd /d %AppData%\Microsoft\Internet Explorer\Quick Launch C:\Documents and Settings\xxxxxx\Application Data\Microsoft\Internet Explorer\Quick Launch>dammit 'dammit' is not recognized as an internal or external command, operable program or batch file. See? Thing is, this worked before! I've checked the registry for any obvious problems or extraneous characters, but there's nothing out of line. Next, I tried it on the VM, and same thing. Then, as I was trying to figure that one out on the VM, I noticed that all the above CU* variables weren't mapping to the correct location. CUDT should go to %userprofile%\Desktop That's what the registry value has for that var. The actual path for %userprofile%\Desktop is C:\Profiles\Kelani\Desktop however, all the CU* variables I created now take me to the corresponding folder of the system profile. CUDT=C:\WINDOWS\system32\config\systemprofile\Desktop CUSM=C:\WINDOWS\system32\config\systemprofile\Start Menu CUSMP=C:\WINDOWS\system32\config\systemprofile\Start Menu\Programs Windows built-in variables work fine. cd /d %userprofile% takes me to the correct user profile directory. Next, I deleted the above system variables from currentcontrolset AND all the backup keys, rebooted and added them as user variables (which completely ruins their usefulness since user vars automatically expand to the actual path. Not ideal. ). Making them user vars stopped the mapping to systemprofile, but the %QL% variable still doesn't work. I also created a system and a user var QLtest=C:\Profiles\xxxxxx\Application Data\Microsoft\Internet Explorer\Quick Launch and neither of those work either. So, now I'm wondering, what changed? Did Microsoft add something evil in those security updates released last night? That's *all* that's changed on those two boxes in the past two weeks. It's odd that they'd both stop working simultaneously, and in the exact same way. So, obvious question, *can* you create a variable with a target like %UserProfile%\Desktop and use it as a system variable so %UserProfile% won't automatically expand, or do you have to create user variables for every user? I thought the former was allowed, but after today, I'm not so sure anymore Leave it to Windows to wait until 3AM to show me another quirk I've never seen it do before. Any ideas? Kel

Found a typo-bug in the last version of tweaks I was able to download. The app says if you find a bug, go to the website, but the website's just a password form, and the download link. Kinda hard to report a bug through ESP Anyway, there's an extra right bracket in this key: ; Speed up Access to .AVI Media Files [HKEY_CLASSES_ROOT\CLSID\{87D62D94-71B3-4b9a-9489-5FE6850DC73E}][b]][/b] <---Extra bracket You may want to run a few checks on the tweak DB to catch common errors like that. Whenever I make major changes to my tweaks DB, I always check for: Extra brackets, } instead of ], spaces before and after brackets, spaces before comment lines, spaces before quotes, + instead of =, etc.. Usually find 99% of them that way. Also, looking forward to that local db. I've been having trouble connecting to the remote database. Being a db-driven app, when that occurs, the app instantly closes. Which is...mildly annoying. Hope the db and project hasn't shut down. :/ Kel

deXter: That page was exactly what I was looking for, and the info in your post was a bonus. I swear MSDN hates me. I *scoured* that site, and that same section on more than one occasion looking for this info, and never saw it. Editflags looks to be so useful, I wonder why it's not more commonly used amongst regtweakers? Sure, those settings are there to keep people from screwing up their install, but for those who know what they're doing (and even when they don't, try it anyway) being able to change those behaviors is pretty useful. For example, a tweak to remove a few dozen useless filetypes from the recent document list might make that feature worth the problems it creates. Same thing for a tweak to remove these two annoyances from a few filetypes: FTA_noEditIcon (0x00000200) -Prohibits the modification or deletion of the icon assigned to the file class. FTA_NoNewVerb (0x00000020) Prohibits the addition of new verbs to the file class. BrowserFlags seems to have some nifty possibilities, too. Anyway, Many thanks for your post. It'll be very, very helpful. Cool avatar, btw. Turn the guy pale white, make the cat look bored and I'd think I was staring into a mirror. -Kel

Validation. Sweet! I expected to get deluged with flamed from people thinking I sounded like an a**. That tends to happen when I post late at night in a sleep-deprived state. Seriously, though. At the risk of contradicting myself, I have one more comment: It bugs me how anal some people can be about security, yet their knowledge of what those actual threats are is practically nonexistent. Take the infamous virus. Chances are, if you grab a file from a reputable shareware repository, it's been virus scanned several times: By the author after creation, by the author's and/or the site's ISP during the upload, by the site upon receipt, re-scanned by the site after virus def updates, and finally, scanned by the user who downloads it. The same goes for email. Virii are simply not as big a threat as Joe User thinks they are. That perception is thanks to some brilliant marketing. It's rare when a single industry can create global paranoia on such a large scale. I've been online in one form or another since 1983. Sure, I got a few bugs in my Apple/Atari BBS days, but since I migrated to the 'net in 1993, I've gotten exactly 12 virii. With the exception of one trojan that my mom accidentally let loose on my box (one of those cute little executable animations she inexplicably loves) the other 11 were obtained when I stupidly downloaded illegal stuff through filesharing and questionable websites. Avoid that, and 90% of the crap we worry about will never happen. Now, spyware and malware. Those annoyances definitely aren't exclusive to questionable sites. But being aware of what each is, and how it works makes it pretty easy to avoid...or at least to recover from. Once I added a robust HOSTS file and started using the Adblock addon for Firefox, I haven't seen a single instance of ad/spy/malware or a popup since. So, if you take a few smart precautions: decent AV, software/hardware firewall, kep your box updated with security patches, use some kind of IP-based blocklist/filter, don't try to set a 24-hour warez downloading World Record, and you'll be OK. Sure, there's always the tiny chance one of the black hats I mentioned earlier might decide to make you have a bad day, but frankly, there's nothing you can do about that other than selling the computer and picking up basket-weaving. I suppose you could begin mastering the intricacies of security so you could design some brilliant solutions. Good luck with that one. Kel

I can't believe the number of people who still use bloatware like *cough*Symantec*cough* and a few unnamed apps that are even worse. I don't care how much RAM some people have. An AV solution shouldn't require 5 automatic services and consume 120-180MB ram when idling. That's just ridiculous. I've used NOD32 for a few years, and even with its unfortunate recent trend towards wasteful memory usage, It still stays under 40MB (average is ~25MB). I'm still happy with it. AVG and a few other smaller packages are also pretty good. The point of my rant is, if you avoid AV and security solutions solely for performance boosts, there's almost always a better alternative. When I saw what software firewalls did to my boxes, I got a NAT router. When I saw a 5-second delay opening freakin' notepad after my former job installed Symantec crap on everything, I got them to switch to something better. I had to take my router offline for a few hours last week to resolder something, and for fun, I started a comprehensive network monitor. (Note: I left my last provider in 2003 partly because a good chunk of my bandwidth was being consumed by fending off the constant portscans and connection attempts from their id*** users.) Well, big surprise, 4 years later, a different provider and a different state, it was 10x worse than before. I watched this monitor for awhile to see what these guys were trying these days. While 97% of the ~10,000 attempts I logged over 12 hours were harmless port scans & connect attempts to Telnet/SSH/FTP/NetBIOS/Game servers, I saw at least 2 separate series of events that were *manual* attempts to infiltrate both routers and every flavor of every OS I've ever heard of. I was impressed. Please believe me when I tell you, you could have an 128 char password, and avoid the web entirely, but there's a lot of people who could still make your box blink like a Christmas tree from halfway around the world. There are vulnerabilities in hardware and software that were discovered by the wrong people. Consequently, they're not reported, and probably never will be. (Honestly, now. How many of us, upon discovering a unique way to break into any box, would share such a powerful secret?). End result: We all remain vulnerable no matter how many patches we apply, or how sexy our firewall is. You guys claiming you have no updates, no ports blocked, no firewall, and no AV protection are just asking for a rude surprise. That's partly because most of you use some form of broadband (Cable users are *really* asking for it.), but mostly because you're openly bragging about it on a high-traffic forum. Good luck with that. Kel

Did you check that locally-saved HTML file to make sure it didn't still have any externally referenced items? (stylesheets, scripts, images, audio, video, server-side includes, etc..) That sounds like the most likely culprit. As for the inability to open it when a browser was already open.. That's...different. But I can see it happening if you'd blocked explorer.exe in ZoneAlarm. I never was very impressed with that program. It seemed to have a hard time differentiating between local and network activity. From what you said, maybe it still does? Kel