Mr Snrub

Step-by-step guide to what you should do: 1. Start the Vista installation process, after clicking Install, once the "Starting Installation..." message appears, hit SHIFT-F10 to bring up a command prompt: 2. Enter the commands: DISKPART SELECT DISK 0 CREATE PARTITION PRIMARY EXIT EXIT 3. Reset the virtual machine, hit F2 to enter the virtual machine BIOS and change the boot sequence as follows: 4. Restart the Vista installation process (go through as normal now, disk 0 partition 1) 5. After installation, Vista will have the following in Device Manager: 6. Install VMWare Tools, and during installation you will get a Windows Defender balloon pop-up to say some system changes need confirming, click Apply: 7. Restart Vista when prompted and your graphics should now be better, and looking in Device Manager you should have:

NET USER username /times:...Does that work in XP Home too, or just Professional? (Never installed XP Home in my life) Edit: Also, the feature is not exactly the same - the method in XP prevents users logging on outside of the specified hours, but does not kick them off if they are already logged on when the time expires. Vista forces a desktop lock when the time period expires so the user has to authenticate to get back into their session, so it checks the time and refuses to unlock.

VMWare provides a virtual set of hardware for the guest OS - any physical hardware in the host is (for the most part) irrelevant. What you need to do is install the VMWare Tools, this installs drivers for the virtual hardware to allow higher resolution & colour depth graphics - but you will not get Aero Glass enabled as the virtual hardware does not provide the necessary support. When you install VMWare Tools in the virtual machine, make sure to check Windows Defender and apply the changes it wants to make to the registry before you restart. On restarting you should have better graphics support, the mouse is no longer captured, but you most likely won't get audio without some messing around with drivers for the emulated hardware (unless VMWare update their Tools).

AFAIK, "logon hours restrictions" are only available for domain users, not local user accounts.

Microsoft KB on "machine check exception" STOP errors: http://support.microsoft.com/?kbid=329284 It looks like either a hardware fault (HDD, controller or cable) or it could be that your chipset or IDE drivers need updating. Do you have the slave HDD connected as a slave on the primary IDE channel? Does the same happen if you use the secondary IDE channel? Do you have another IDE cable to test? Check for any updated drivers for your motherboard - chipset, IDE in particular. Maybe try forcing the disk access to not use DMA (either through the BIOS or in Device Manager in the properties of the IDE channel), and/or disable write caching on the disk itself (Device Manager).

Be aware of changes made to the OEM EULA, removing the loophole of "non-peripheral hardware" which people exploited: http://blogs.msdn.com/mssmallbiz/archive/2.../07/461961.aspx The absolute wording says OEM products must come preinstalled on systems provided by the system builder (OEM), and AFAIK OEM licenses are not transferrable. OEM software has been abused a huge amount over the years, it is intended to be discounts for system builders that they can optionally pass on to end users and not meant to be sold as installation media. The system builders get the discount because they are responsible for supporting the end users, not Microsoft. In effect, anyone selling you OEM software is the one responsible for supporting you if you have problems with the product. Just an FYI.

Clarifying the situation: XP client KHAZANA has a local user account UUHM which is a member of the local Administrators group and has a local profile. Upon logging in today, UUHM has a default user profile. This means all user-specific settings are gone, anything under My Documents is no longer visible, all history, etc. are gone. There are 2 folders in C:\Documents and Settings: UUHM (the original profile) UUHM.KHAZANA (the newly created profile) It sounds like the user profile in C:\Documents and Settings\UUHM is corrupt and so Windows has created you a new one. Did your machine not shut down properly recently and you had to power off? Have you looked in the System event log for any USERENV errors? While the bulk of the profile (documents & history) can probably be recovered, if NTUSER.DAT is screwed up then your user settings will need to be reset. As C:\Documents and Settings\UUHM.KHAZANA is a brand new default profile, I would first try to copy the original NTUSER.DAT into here to see if it works. To achieve this, first grant another user account full control of the 2 profile folders temporarily - by default the users are owners and rights are not inherited so you need to allow access. Secondly, as the logged-on user has their own NTUSER.DAT file locked, you have to log on as this other user you granted rights to. Then run this comand at a command prompt: copy "C:\Documents and Settings\UUHM\NTUSER.DAT" "C:\Documents and Settings\UUHM.KHAZANA" /y Not log back on as UUHM and see if your user settings are restored. If another user profile is created then it looks like NTUSER.DAT is screwed up and would have to be deleted to revert to the original user profile.

Okay, let's try to clarify the issue you have... First question - "can't edit, remove or add anyone"... - who is in the list? - what happens if you attempt to add a new user? - what happens if you attempt to remove an existing "unknown user"? "Simple File Sharing"... this is to do with network shares, not NTFS security permissions... are you looking at the Sharing tab inside "Permissions" rather than the Security tab of the folder?

There should be no problem with what you are doing I think, I just emulated your setup in VMWare using W2K and XP and got the same prompt. Configured the disk partitions in the order: slave disk - 6GB (100%) - becomes C: master disk - 20GB (16.66%) - becomes D: master disk - 100GB (83.33%) - becomes E: Installed W2K on C:, got prompted that D: format needed to be FAT32, continued through W2K installation. Rebooted with XP CD in the drive, selected to install on D:, selected to change file system to NTFS, continued through XP installation. Disk Management in either OS can be used to format the 100GB partition as NTFS and assign the letter P: to it. You could set up the 120GB disk as the master but I don't think there would be much functional difference - if in the long run you intend to phase out W2K then it would make more sense to do that, and also to have XP installed on the 20GB partition as C:, though.

On the Security tab where the users with permission are listed, you should be able to select the "unknown user" and click Remove to take them off the list. Unknown users will be ones that exist on other installations of Windows and so cannot be dereferenced by their GUID. If I created an NTFS file system on a USB memory stick and added my local users with permissions, then we took the stick and connected it to your machine, you would see lots of unknown users. There are a few "well known" GUIDs like the local Administrators group which are tokens which should work across different systems, but local user-created users would have (effectively) unique IDs and only make sense to the local SAM database. What you can do is assume ownership of the folder and give it to a specific local user or group on the target system, then the permissions can be changed. On the Security tab, click the Advanced button, then select the Owner tab and you can assign ownership to a specific local user/group.

Yes, because your D: drive is the master disk it needs to be involved in the boot process. If you continue through that step you should be prompted to select a file system format for the C: partition, FAT32 or NTFS - this is where you select NTFS. When you come to install XP on D: you should be able to change the file system on D: to NTFS.

I would approach it this way: - boot off the W2K CD - format the primary 6GB disk as NTFS - create the 20GB and 100GB partitions on the secondary disk - install W2K on the primary disk - boot into W2K after installation completes, use Disk Management to format the 20GB and 100GB partitions as NTFS, assign P: to the 100GB partition - boot of the XP CD and install on the 20GB partition Now you have a dual-booting W2K/XP setup using C: and D:, with a common P: drive. Personally, I would split the 120GB disk into 40/80, but that is because I tend to use large installable products that like to reside on the system drive. Be aware that local user accounts created in W2K will not be resolvable when booted into XP, and vice versa - so when you assign permissions on the P: volume you will need to put both in, and the "other" OS users will appear as GUIDs when you view the security tab.

If Windows isn't even recognising a device is plugged in when you connect it, then this is a hardware problem, not a driver or Windows issue. Check the device definitely has power and the cable is securely seated at both ends, and that there is no option to enable on the device to make the USB port "active" (unlikely, but you never know). If Windows still doesn't pick up a device connection then it sounds like the cable or the device is not functioning.

You replaced a single-core CPU with a dual-core one and now that message appears at POST every time you power on the computer, but hitting F1 allows Windows to load correctly? The message states exactly what you need to do - contact HP Support and get the necessary details from them, this has nothing to do with Windows. I assume your PC is a branded HP one so you have a support pack that came with it, there should be details on getting support in there. God jul och gtt nytt år

Vista betas won't install to "raw" disk partitions just yet. What you should do is format the partition as NTFS then restart the VM and installation will go through. VMWare have this documented here: http://www.vmware.com/support/guestnotes/d...s_winvista.html This is the relevant bit:

What you are describing there is the principle behind the Remote Installation Service (RIS). A client image is stored on a W2K or W2K3 server and the client machines boot using PXE (or from a CD) then have their installation files copied down across the network during install. Couple of documents detailing the process: http://www.microsoft.com/technet/prodtechn...o/remoteos.mspx http://technet2.microsoft.com/WindowsServe...8b41fa1033.mspx

Correct, if XP is set to use the "welcome screen" then CTRL-ALT-DEL brings up the Task Manager directly. If the classic logon is enabled (or you are joined to a domain which does the same thing) then CTRL-ALT-DEL brings up the Windows Security dialogue. To toggle the way users logon: Control Panel / User Accounts / "Change the way users log on or off" - "Use the Welcome screen" tick box As an aside, Process Explorer from SysInternals is a much richer task manager, if you spend a lot of time looking at running processes: http://www.sysinternals.com/Utilities/ProcessExplorer.html

STOP 0x8E = KERNEL_MODE_EXCEPTION_NOT_HANDLED 0xC0000005 = STATUS_ACCESS_VIOLATION A kernel mode driver has tried to access memory it doesn't have rights to, so one of your 3rd party drivers is buggy or a core one could be corrupt. The system event log should have a record giving a little bit of information regarding the affected driver - although it is possible that this driver was the victim of memory corruption from one of the other drivers on the system. To check for corruptions when the occur, rather than when the corruption is detected and brings the system down, you can enable special pool: http://support.microsoft.com/kb/188831/EN-US/ Alternatively you can use the "driver verifier" tool to enable debug logging on a per-driver basis (start with all 3rd party drivers tagged): http://support.microsoft.com/default.aspx?...kb;en-us;244617 When you have this extra debug logging in place then the memory dump should give a more accurate root cause for the crash, and the stack of the running thread should idenify the process and driver.

The secure attention sequence should bring up "Windows Security" on XP. Alternative ways to bring up Task Manager quickly: - right-click the task bar and select Task Manager from the context menu - hit SHIFT-CTRL-ESC

You already found out the reason, but FYI there is a better approach to fixing this. Vista changes the boot sector on the active partition to a new format which does not use the BOOT.INI file at all. The \BOOT folder is created and contains a few tools for modifying the boot sequence. One of these tools is FIXNTFS. FIXNTFS -xp changes the boot sector to the classic "XP" style, using BOOT.INI to describe the boot options. FIXNTFS -lh changes it to the new "Longhorn" style, where the boot menu options are edited using another tool called BCDEDIT. What you should have done after (or even before) removing Vista is to run FIXNTFS -xp, then edit BOOT.INI to remove the entry for the Vista partition and amend the default boot option.

Wow I didnt know that how do you go about doing that? How do you monitor what ports are open or not? Mind I am running XP Home yuck so I prob cant do that. It is only possible to list the ports/protocols you do want to accept, you can't specify exceptions. So to block a single port you would need to list the other 65533 individually. This filtering interface is more for hardening servers with specific services in controlled environments - e.g. only having TCP port 80 open on dedicated web servers. Properties of Internet Protocol (TCP/IP) in any of your network adapters -> Advanced button -> Options tab Highlight TCP/IP filtering, click Properties Configure the TCP & UDP ports you want to accept traffic on, and/or the IP protocol numbers you want to accept - note that this affects all network adapters on the system. Another drawback of IP filtering this way is that it does not take into account the source of the attempted connections, so you can't specify one rule for internal clients and another for external ones. Microsoft article on Windows 2000 TCP/IP features: http://www.microsoft.com/technet/itsolutio...vg/tcpip2k.mspx For workstation OS's the Windows Firewall is a better way of controlling which applications can act as servers, through exceptions in the Windows Firewall applet in the Control Panel. To monitor "open" ports you can use the command line "NETSTAT -ANO" and see which are in the "listening" state. e.g. Sample output from XP Pro: C:\>netstat -ano Active Connections Proto Local Address Foreign Address State PID TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 1580 TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:1723 0.0.0.0:0 LISTENING 4 TCP 0.0.0.0:3592 0.0.0.0:0 LISTENING 528 TCP 0.0.0.0:42510 0.0.0.0:0 LISTENING 364 TCP 127.0.0.1:1057 0.0.0.0:0 LISTENING 128 TCP 192.168.1.1:139 0.0.0.0:0 LISTENING 4 Alternatively you can run something like TCPView from SysInternals and it gives you a lot more detail too, in a fancy GUI: http://www.sysinternals.com/Utilities/TcpView.html

VMWare 5.5 with NAT connectivity to XP Pro SP 2 running Vista works fine here. Host OS is a DHCP client on a LAN NAT'd to the Internet. NIC & display adapters appear fine in Device Manager when VMWare Tools is installed, just the audio adapter doesn't get a driver by default. When you installed VMWare Tools, did Windows Defender kick in and block 2 or 3 actions that require approval? That might have prevented some necessary registry modifications.

More correctly: noone who (knows someone who) does know is reading the posts, more like. I'm sure if there was someone working on a 64-bit LDDM driver that they would know about it, for example. Okay, sorry, I'm using build 5276 which is a "post beta 1 tagged as beta 2" if it makes you feel better.

Yes, this is correct - an application installer should identify itself as a 32-bit or 64-bit application and the OS puts it into the relevant Program Files folder. No, there is no need for a second OS if the application runs happily in WOW64 mode (32-bit emulation on a 64-bit OS). 32-bit apps (running in user mode) should run happily in a 64-bit OS via emulation (see above) so you don't need a 32-bit OS for those.If your printer/scanner/webcam/whatever manufacturer has not produced a 64-bit driver and there isn't a compatible alternative, you cannot use it in XP x64 Edition. You absolutely, positively cannot use 32-bit drivers or run any 32-bit kernel-mode code on a 64-bit version of Windows. For AV I use avast! 4.6 64-bit.For a firewall I use the Windows Firewall until ZoneLabs get a 64-bit version of ZA Pro produced. MS Antispyware is your best bet for malware detection.

I am running 64-bit Vista Beta 2 which doesn't have native nVidia support beyond the 6800-series (no use for my 7800GT), and nVidia only have 32-bit Vista drivers. I can convince Vista to use my XP x64 drivers (but not via SETUP.EXE) but as this is just xDDM I don't get the Aero interface like I do on my ATI x800 Pro system. Can't find any public statement from nVidia, only a few people asking the same question as me with no reply, and nVidia don't appear to have a public channel to ask the question. Anyone here got contacts at nVidia that might be able to find out when 64-bit LDDM drivers will be here to play with?