cluberti

You could try it for sure - but I think a repair install or a clean install at this point is probably going to be your best option.

What are the specific errors you are getting? Do these errors happen when doing specific tasks in Windows? How much physical RAM is in the machine? How long has this been going on (i.e. has your system ever worked properly without these errors)?

I notice you use quite a few explorer.exe shell extensions, and since your stated problems lie entirely in the shell, disabling all shell extensions and startup items that are non-Microsoft and not absolutely necessary to boot up would be a good start - download autoruns and shellexview, disable all non-Microsoft items in both (unless absolutely necessary to boot up, which they shouldn't be, but I've seen it happen), and reboot. See if the problem persists.

You could probably write an application to do this ala WU, but I'm wondering what types of applications it would support, what versions, how far back in versioning, what database engine to use backing this, and whether or not the BITS engine is used to transmit the updates (ala the WU client).

Hopefully someone there can help, but one other question I had was is there a specific reason to boot to x64 WinPE? I know there are some limitations when loading up Vista, but it should be OK for installing almost any other OS (or at least getting files down to the drive to continue install). What produces the need for x64 PE for you? Just very curious...

Yeah - the way to avoid it is to use a driver that doesn't exhibit the problem - if you're integrating a driver into setup, you'll probably want to do some trial and error on available drivers for your hardware to see if any work. Otherwise, you're either going to get the pop-up, or you can skip integrating your driver (and use the standard VGA) and install post-setup.

The chipset is the thing here, especially on 2K (this almost maybe might've worked on 2K3 and XP in safe mode, but it'll fail on 2K every time). Your only option is a repair install, or, go back to the old machine and uninstall the VIA drivers. Before you reboot after VIA driver uninstall, download and run sysprep to do -pnp and -mini. This should work, if you want to spend the time doing it.

You might want to post this in the WinPE section of the forum, as I'm not sure how your in-house application works. But, maybe I can help if you answer a few questions: 1. Does your PXE bootloader do hardware type detection on load? 2. If you rename the boot.wim file for each architecture to something different, would you be able to add them to your PXE server as separate images? I'm not sure you can change the boot folder path in the .wim, so you may be out of luck. See what people say in the WinPE section, though, before giving up .

Yes, this has been discussed many times before here, but that's OK. The problem comes from the video driver that is being installed into your image - the driver install routine likely has a monitor check phase, and it's prompting you for the driver (this usually doesn't happen with the same driver during regular Windows, but on an install (where not everything is quite set up yet), this can happen.

I'm not sure that's odd at all - that is the only place in the entire GUI where those notification icons would be located, so why not put them in the notification area's control properties dialog?

The first GUID is for shdocvw.dll, and the second GUID is supposed to represent the "Shared Folders" global folder. What it looks like is that there was something wrong with shdocvw, and instead of your system showing the "Shared Folders" icon, it was showing the GUIDs for the code path that would've been used (shdocvw would've been called to display the folder and it's icon, but instead of showing the Shared Folders folder, it showed a folder with the shdocvw GUID). It would also cause all of the other "User" folders that normally get displayed there to either not display, or display as GUIDs as well (which it looks like that is what happened from the screenshot to the Administrator's folder). Problems with shdocvw would also cause drag-and-drop and other OLE problems as well, so that would also explain problems with programs that register with shell extensions.

You can indeed create a user called SYSTEM, and you can even give it a full access token, but the SID won't match the Local System account's SID, so it's not a true SYSTEM account. Again, use an elevated command prompt (if UAC is enabled) and run psexec -s cmd to get a SYSTEM command prompt, but be very careful - anything you run from there runs with the creds of the Local SYSTEM account.

IE7 is out only for XP, 2K3, and of course Vista. 2K and lower clients will not get an IE7 package.

amd_64 - 64bit components, only used on x64 installs wow_64 - 32bit components or support components for 32bit compat installed on x64, only used on x64 installs x86 - 32bit components installed on x86, only used on x86 installs

You don't need to do that - simply create 2 boot images pointing to the proper boot.wim (one pointing to the boot.wim from the x86 CD and one pointing to the boot.wim from the x64 CD), and name them something different (obviously). When pxeboot.exe is called (and assuming you've run the command "wdsutil /set-server /architecturediscovery:yes" on the RIS server and restarted the services), it should give you both options by default on x64 machines - x86 machines will still only see the x86 boot PE.

Unless you have access to the source for these utilities, or understand the device and want to write your own software stack for it, you're stuck outside looking in on x64 with that device. It's not trivial to convert software and drivers to x64, but it's not that difficult either (especially when you're doing it for your own x86 software ). It's the catch-22 for companies like these - there's no real market push yet for x64 due to a lack of software and driver support, but that's also the reason there's no real market push...

I'd have to suggest that you check safe mode w/ networking, because that just seems odd - like a driver issue (obviously the hardware's fine, as it works in x86 - the only real difference would be drivers).

If you're running an x64 version of Windows and are worried about memory requirements, that seems silly to me. But, to each his or her own - like I said before, this kind of question will get all kinds of responses, with no "right" answer.

I've found Vista to do the complete opposite on my laptops and tablet PC's - however, my WAP supports the wireless card power features of Vista, so I do well there too, but Vista under it's lowest power setting runs for a good 4 - 5 hours on my Thinkpad X under regular use.

It doesn't work in Vista, because Vista users no longer log into session 0 (the session a console user logs into in XP, shared by the SYSTEM account). Therefore, the window will open, but you will not be able to see or interact with it at all (without some serious hacking with the debugger). An easier way to do this is to download psexec and run "psexec -s cmd". That'll give you a SYSTEM account cmd prompt - note that you obviously operate a SYSTEM-level cmd prompt at your own risk, so be careful.

Right, but if you run a regmon, do you see the value being set when you click the "remember" box? And do you see it being read when you attempt to open a file? Regmon should show us this...

Doing that will break shell components, so not a good idea all around. However, you may be able to create a software restriction policy (either locally on the box or in the GPO that applies to the OU those machines are in) to disallow iexplore.exe.

As to why it happened, I couldn't say (something on the system changed, and you'd have to think back or go through your log of changes that you probably don't keep to see what actually changed). However, to add the base domain name to the trusted sites, you'd add just the domain and tld to the trusted sites list. For example, if you wanted to trust a site called "site2.somewhere.somewhereelse.microsoft.com", you could simply add "microsoft.com" to the trusted sites list.

Have you tried using the "Enable VGA mode" boot option? http://support.microsoft.com/kb/315222

So are you saying the issue doesn't occur when in safe mode w/networking? If you have a machine with the issue, and you then reboot into safe mode w/networking, it doesn't continue? Or you haven't tried yet?