cluberti

Hmm, well, it's still buggy I guess. Press Intel until they give you a fix .

I've got a Dell laptop with the same chipset that works only with build 1855, which I had to get directly from Intel as they were not out of beta yet. I had similar issues (hence why I asked if it repro'd in basic and classic, which it will if it's the same issue) and installing .1855 has worked on that box (running RC1 and RTM) so far without further issues. See if you can contact Intel and get them to give you a link to this version.

If you want to buy an upgrade version, yes. However, OEM full versions are only slightly more expensive than upgrade versions, so consider that instead if you can.

Does it repro when the theme is Windows 7 basic or Windows Classic? I know the Intel drivers for Win7 have been problematic since the beginning, for what it's worth. Let us know what happens in basic or classic.

Keep it here, and edit the title if you have to. Please don't double-post, even if they're not *exactly* related. It's still the same game, with the same ultimate problems (you can't play it).

Agreed - it almost sounds like a memory leak (problem only occurs over time) and only a reboot cures it.

Note I can reproduce the services.msc repro on my 9800GT with the latest drivers from nVidia, but I cannot reproduce the CPU issue (nor does the issue reproduce in any other window - it appears limited to services.msc, as I cannot repro it in firefox, IE, windows explorer, the control panel, device manager, perfmon or resmon, etc). So it does partially repro on my 9800GT, but again, I'm not seeing it on my 3650. This would make me believe it is indeed a driver issue, as Direct2D is included in Windows 7. Also, seeing as it seems perhaps limited to services.msc, perhaps there's something about that mmc that's triggering it specifically.

Well, if you can repro it with an RTM parent (I'd suggest testing), I'm guessing you'd have found an issue to file.

No, they have WDDM 1.1 drivers, but nvidia's drivers have historically been not so good. I'm using again a 3650, but a 3850 or a 4850 (or 4870 or 4890) Radeon are probably all fine with this. I'm going to build Win7 on my 9800GT box to see if it has an issue or not.

It's also much older hardware - only the 2xxx, 3xxx, and 4xxx cards get WDDM 1.1 drivers from ATI, so it's not a good test. You're using the old WDDM 1.0 drivers, so you're going to repro the same bugs as in Vista.

If you've upgraded it to SP2, the role was upgraded, so there's no need to remove and re-add it. However, you really do need to do the rest (remove ICs, shut VMs down, merge snapshots, bring them up, and re-install the ICs). You have the Hyper-V beta integration components installed in your VMs running on the SP2 Hyper-V, which is known to cause problems (I know this, because you cannot install the Hyper-V RTM or SP2 IC bits in an XPSP2 guest, but you could with beta, so if you've got ICs there I know that you've got the beta bits installed in your guest OSes).

Well, for what it's worth I repro'd those steps on my own box with an ATI Radeon 3650, and I didn't see either of those problems. I'm pretty sure those problems are the nvidia driver set+hardware, not Windows. Again, I cannot repro either the slow redraw or the high CPU, and I'm not using an nVidia chip, fwiw.

Is the server in question a 2003 or 2008 (or 2008 R2) WDS server? Also, are you sharing the NIC between the hyper-v hosts and the OS? If you've got a NIC that isn't bound to hyper-v, try that as well to see if it changes anything.

Yes.

Well, it only took nVidia until SP2 to sort their Vista video drivers, let's hope they get better at it with Win7 and network drivers. As to folks with problems still on RTM, let's start making a list of HWIDs that are causing the issues. Look at the properties of the device in device manager, go to the details tab, and click "Hardware Ids" from the list. Post the device name here, along with the Hardware Id, and we'll start seeing if there's anything in common.

Yeah, the last.

I just had a similar issue, and I had to clear my cache and reboot (don't know why, although I'm assuming something had a lock on the msfn cookie...) and now everything is working again. I don't know what you're seeing though - are you logging into www.msfn.org/board or msfn.org/board (it matters)?

It's more of a "just in case" rather than anything else, nothing more. Again, I've never personally seen any issues with it, but it's a "just in case" so that you don't run the risk of problems later. You're free to do what you want with your system, but I'd recommend leaving it as there's no harm in doing so, and there's at least that .001% chance of problems if you do remove it.

Unfortunately, the board's current design only allows for one choice for a custom field.

Well, that and to get drivers certified by Microsoft with the WHQL certification, they MUST pass the x64 tests, and be signed (so they'll run on x64 Vista or Win7). While I'd recommend Win7 over Vista, if you are using XP x64 and that's what you have you're going to have to make the decision to run with obviously poor drivers but get better CPU performance, or go back to XP 32bit and run with obviously better drivers for your hardware there, but without the support for the additional 32 registers on your CPU or the ability to use more than 4GB of physical RAM.

It's not documented publicly, but indeed the $hf_mig$ folder is used for uninstall of updates, and there *may* be an update out there that uses the folder to determine which binary to install, but that is not what the folder is for, and I've never personally come across one that uses the folder for anything more than uninstallation file backup. With the advent of using update.exe for XP+ updates or the servicing engine .msu's for Vista+, this should not really even be possible anymore as the update itself contains it's branching and versioning information, so unless you're running NT4 or 2000 this should be 100% safe to delete. Also, any time you install a service pack and you choose to clean up the uninstall files (Vista/Win7) or chose to install it with the switch to not save backup files (XP/2003/previous), you can safely remove the $hf_mig$ folder after installing the service pack successfully, as you can never use those files for hotfix uninstall of anything prior to the SP anyway. If you're paranoid you can always move it's contents to another location, but the only thing I would suggest is to make sure you never delete that folder itself, only it's contents. You should be very safe in doing so.

Well, yes and no - the virtual environment is always running, you just don't see it. The apps still run in a VM, it just doesn't look like they are (well, other than the XP title bars and such on a Win7 machine).

Rules edited for better reading, and sig size allowed has increased. Let us know if this does not clear it up for you.

Yes, the previous version supported it, but it wasn't required (and it didn't use it as extensively as VPC in Win7 does). As to RAIL, it means you see the apps as icons in the Win7 start menu, and their UI runs as if it was running in the Win7 environment, but they're really running inside a "hidden" XP VM that's running in the VPC. It's similar to VMWare's UNITY in Fusion for the Mac, if you're familiar with that.

The barcodes are strictly for tracking product purchases, and don't relate to the product ID on them in any way. I've asked this of MS in the past wanting to do something similar, and they confirmed that they use them for product tracking only, to count units of a product and version that are sent out to distribution end points or something other, and not to track anything else related to the COA.