cluberti

Is it creating a bluescreen and then rebooting, or is it just hard resetting? If it's crashing (and not completely resetting), consider configuring your PC for a complete memory dump, get a dump of the next crash, and then compress/upload it somewhere we can look at.

They came up with it because it fixes the problem, and still allows for backwards compatibility so that calling an API results in the same behavior as it did in previous versions (minus deprecated functions, of course). Microsoft is not Apple and they can't just kill off the way Windows works (ala OS9 to OSX) just to make things "easier". It's done this way so things "just work" as much as possible, and the majority of Windows users care about this FAR more than they miss 1 or 2 gigabytes of disk space on their 500+GB hard drives. Well, that's a horse of a different color. Windows doesn't provide anything really outside except for .NET, so a change there isn't going to give you much releif, and re-use of WinSXS makes sense from a dev perspective (why do things differently when you can re-use this methodology and have things be consistent). Complaining is OK, but a failure to understand why it works the way it does is where the bulk of the complaints come from. And, also, removing languages not used during install (either via the answer file or vLite) trims WinSXS down tremendously, and is a supported (well, using the answer file anyway) and documented procedure, and a way of mitigating this bloat you speak of.

I'm not getting involved in this virtual "mine is bigger than yours" embarass-fest, but mine is bigger than yours .

Vista x86 is fine as an OS, although I would run XP SP3 on that machine simply because it was originally designed for XP, and likely not be able to run Aero at all with the lower-end graphics chipset I'd expect in there.

I don't see anything that technically would be causing problems listed there, so it may be more beneficial to actually be able to see the memory dump files. I would strongly suggest configuring the machne for a complete memory dump, and the next time it occurs you should have a memory.dmp file in the \Windows1 directory that you can compress and upload somewhere for us to look at. Edit: Tarun is right, I missed those (don't do HJT logs without coffee, apparently).

Yes, "those idiots" indeed. We really shouldn't have minimum requirements at all, we should use something different. Perhaps, maybe, the Windows Experience Index? Sorry, couldn't resist. And yes, if you run XP on a 233MHz machine with 64MB of RAM, you'd be p***ed at XP as well if you wanted to do anything other than boot. Holding Vista accountable for running a machine at it's bare specs (just like people tried, and failed, with XP back in 2001) is not something that will be paid much attention to. Running XP on a machine with 512MB of RAM (when the minimum spec is 64MB) is akin to running Vista on 4GB RAM (64 * 8 == 512, 512 * 8 == 4096). So, if it is fair to say that the average XP user would have something between 800MHz and 2GHz with 512MB of RAM, to get the same Vista experience we would probably expect a 2+GHz processor with 4GB RAM, which is *surprisingly* about the sweet spot where Vista runs very well. The only add would be that you would want to have a better-than-basic video chipset, which XP did not require, so I'll give you that as a concession .

Well, I have to say that your opinion is far from the truth. UAC was two-fold, one to force developers to *finally* write LUA apps that would work for non-administrators, and two, to allow some protection (even when admin) to the system when something (legit or otherwise) attempted to perform an operation on a system-level area. It's not a security measure, although it functions as a pseudo-security device, it's more of the stick to developers (now that the carrot has failed).

DLL hell was caused by two things - one, dll stomping (replacing a .dll file in \system32, and later also in dllcache, with a different version than is shipped with the OS and service pack and hotfix level), and two, shared in-memory .dll mapping. Registry corruption can also cause it, but that was relatively rare.WFP sort of stopped this by not allowing an app to overwrite a system protected .dll without using the APIs to do so, but nothing stopped an application from calling said APIs and creating dll hell, even on a 2000 or XP system with WFP enabled. As to your answer of solving .dll hell, you have shared .dll files so that standard Win32 APIs are available and expected, based on OS, service pack, and even perhaps hotfix level. Your suggestion of local .dll files solves nothing (in fact, you end up with the same as WinSXS, but not centralized) and still does nothing to address memory mapping issues. You argue not to waste space on disk with WinSXS, yet you suggest the *exact* same scheme. Also, WinSXS *is* virtualization for *all* apps - they call an API in a .dll they expect in system32, but the OS instead redirects that call to one in WinSXS depending on what they called and what version of the .dll was expected, if it differed from the one in \system32 (or another system location). So, WinSXS does both of the things you describe as "fixes" to the dll hell problem. Coincidence? I think not .

+1 for the questions raised here. If she's done it before to someone else, she's more apt to do it again (but this time it might be *you* who's the guy on the phone, while she's with the "other" man). This is the road of pain and suffering, I've been down it myself. You need to realize that you aren't special enough to have her "be mature" with you - her last two men (at least) were not, and neither will you be. And it's not you either, it's her - she probably can't stay tied down, and you'll be just another brief stop on her road.

The answer has been given. All other possibilities are different shades of illegal, so shutting down this thread. Buy the DVD, or borrow someone's legal copy if you can find one. Always better to have your own though, so if you can, buy the DVD from MS.

I would have to politely disagree - using hard drive space or not using it doesn't make the device any more or less 'green'. Also, if Windows doesn't use it, meaning *you* want to use it for storage, that's only an argument for more space for your stuff (you're still going to use the space). I just fail to understand the complaints of people with 500+GB HDDs complaining that Wndows uses 4 - 8% of the drive. Why buy a 500GB (or larger) drive if you aren't going to use it? Also, the complaints about WinSXS only benefitting tech support are largely just flamebait. DLL hell affected EVERYONE using .dll files, users and developers alike (partly because the darn developers would write to a specific version, and then install that version - rather than using the one that shipped with the OS and use those features). It means users no longer have to worry about what apps they have installed when installing another app, and worry if this version is going to overwrite that version, and cause one or the other to fail (or both). It's not perfect, but with 500GB HDD standard on most new PCs (and even 160 and 320GB HDDs standard on most newer laptops), this is probably the best solution all around until something better comes along (if at all). Again, you are free to your opinion, but this is like complaining that Vista caches up to 90% of the available RAM in the box to make the system faster, rather than leaving it unused. You paid for the resource (RAM or HDD space), why not use it for something constructive rather than let it sit fallow and have some other OS problems go unsolved? I have to disagree with your complaints.

Yes, Dell storage drivers are the cause. Update to the very latest versions (posted after January 2008) and this should resolve the issues. You'll need these to run SP1 anyway, which you should be doing unless you have some specific reason you can't run SP1. Running Vista RTM at this point is just crazy without a good reason (like, some app doesn't run with SP1 installed, for instance).

Compression will result in slower opening of the file (assuming these will all be hits over the network) and a bit more load on the host CPUs and memory, but there's nothing inherently bad about doing this.

I'd say your best bet is to use the network as-is, but get in (if possible) with the network admins at your residence or the IT dept. You'll find that there's really not going to be a technical fix to this, but a social angle is a much better option. Otherwise, what geek said is pretty much spot-on.

This hotfix is included in Vista SP1. If you're seeing this as an available update (first available in October of 2007), you are definitely not running SP1. Vista RTM (even with the "reliability patches" applied) is still FAR from stable compared to SP1.

If these are two distinct, separate domains in different forests (and not just two child domains in a single forest), then yes, this is the preferred way to accomplish this. You can review this technet article for cross-forest access to resources if you want to try a different method, for instance creating a (security, not distribution) global group in domain B, adding the domain B users to the global group in domain B, and then creating a (security) universal group in domain A and adding the global group from domain B to this new universal group. Note that this will only work if you are in 2003 native or higher on both domains.

Well, it's saying it found files on the system with lesser versions than the hotfix files - do 2 things if possible: 1. Make the following registry modifications and reboot: Key: HKLM\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Trace Value: Flags Type: REG_DWORD Data: 00000007 Value: Level Type: REG_DWORD Data: 00000004 2. Search the entire system for all of the files updated for IE7 on XP listed in the latest update to see if these files exist *anywhere* else outside of the \windows\system32 and \windows\system32\dllcache folders. Windows Updates is scanning the system and finding at least one IE file on the system that is not a correct version.

You're getting two different bugchecks - BAD_POOL_CALLER (0xC2), SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e). The callstacks, however, are always one of these two: 7E: 0: kd> k ChildEBP RetAddr 8bd67af0 8219a897 nt!CmpFreeView+0x21 8bd67b04 8218d626 nt!CmpDestroyHiveViewList+0x86 8bd67b60 8218b224 nt!CmpInitializeHive+0x3de 8bd67bd8 821848c5 nt!CmpInitHiveFromFile+0x19e 8bd67c18 82182d4c nt!CmpCmdHiveOpen+0x36 8bd67d14 82182f81 nt!CmpFlushBackupHive+0x2fd 8bd67d38 8225deb7 nt!CmpSyncBackupHives+0x90 8bd67d44 8203c41d nt!CmpPeriodicBackupFlushWorker+0x32 8bd67d7c 821d9b18 nt!ExpWorkerThread+0xfd 8bd67dc0 82032a3e nt!PspSystemThreadStartup+0x9d 00000000 00000000 nt!KiThreadStartup+0x16 C2: 0: kd> k ChildEBP RetAddr 8bd5fa6c 8210500c nt!KeBugCheckEx+0x1e 8bd5fae0 821ad91b nt!ExFreePoolWithTag+0x17f 8bd5faf0 821ad897 nt!CmpFreeView+0x31 8bd5fb04 821a0626 nt!CmpDestroyHiveViewList+0x86 8bd5fb60 8219e224 nt!CmpInitializeHive+0x3de 8bd5fbd8 821978c5 nt!CmpInitHiveFromFile+0x19e 8bd5fc18 82195d4c nt!CmpCmdHiveOpen+0x36 8bd5fd14 82195f81 nt!CmpFlushBackupHive+0x2fd 8bd5fd38 82270eb7 nt!CmpSyncBackupHives+0x90 8bd5fd44 8204f41d nt!CmpPeriodicBackupFlushWorker+0x32 8bd5fd7c 821ecb18 nt!ExpWorkerThread+0xfd 8bd5fdc0 82045a3e nt!PspSystemThreadStartup+0x9d 00000000 00000000 nt!KiThreadStartup+0x16 Both are the result of a driver fault. I'd say that this is not a memory problem, as it's always the same callstacks, and always the same hive or pool tag. You have a misbehaving driver, but you're only gathering minidumps which are not helpful in this scenario. Please configure your system for a complete memory dump, then when you get your next crash you'll have something useful.

Those are pretty much it when it comes to free A/V that doesn't come with the personal use only tag. The real question is, would one of those free products meet your needs? If not, you'll have to pony up for something more substantial.

If it's a virus, using an offline virus scanning disc is probably in your best interest. Avira makes a good one.

I have to second that disabling those services should not cause that type of delay. Usual logon delays are network or DHCP-related, so if you're sure you aren't having DHCP problems you could try re-enabling Windows Update and Error Reporting services to see if either of those is trying to do something, but can't (thus causing the timeout) to be safe, but I don't think that'll do it. I'd try it though, just to be safe and sure they aren't.

So, to clarify, you installed Office 2007 Professional on your XP Pro SP2 work machine via a set of installation files from a network share, and used your employer's license key for Office 2007 Professional and it worked. Under the home usage program of Software Assurance, you have the rights to take the same home and install it there (on one machine), so you installed it on your XP Home SP2 machine and when you put in the Office 2007 license into setup, you received an error regarding the product key?

264061 Home Folder Is Searched First When You Try to Run a Program http://support.microsoft.com/default.aspx?...kb;EN-US;264061 306850 Programs start slowly or slow logon if the network connection to your home folder is slow http://support.microsoft.com/default.aspx?...kb;EN-US;306850 So you would need both the StartRunNoHOMEPATH value and the SafeDllSearchMode reg values, at the minimum. I would always recommend InfoCacheLevel and NoRemoteRecursiveEvents as well.

Internet Explorer does not implement on<anything> events for option elements in a select list. What you are doing is never going to work in IE (it doesn't work in IE8 either).

To answer your questions, yes they're standard cables (although I always buy the Enermax cables as they're of good quality) and yes, they clip into the PSU so I'm not worried about them once set up and tested. I don't really monkey with my modular PSU's unless I'm adding hard drives (so I'm adding SATA power cable bundles), so I'm also not worried that I'll wear out the clips either. It's nice to be able to have *only* the plugs I need coming from my PSU into my case (I'm pretty ridiculous about cable management, airflow, and neatness in a case, so this also appeals to my obsessive-compulsive case management as well).