cluberti

For now, yes. There's no reason to run Vista on hardware that barely meets the minimum requirements. You wouldn't really consider running XP on a box with 128MB of RAM and 1.5GB of hard disk space and want to do the same things, would you?

Unless you're still running Vista RTM, this statement makes no sense. If you're still having trouble with Vista after SP1+updates, you should probably start looking elsewhere for the root of your problems than Vista.

I believe you can go into the power options control panel applet and assign hibernate back to the shutdown menu, although unless you actually need hibernate over sleep, sleep is a more preferable (and quicker to resume) option.

Open Device Manager (devmgmt.msc) and do you see your network adapter installed under the Network Adapters? I'm guessing perhaps it is not, so make note of what is installed under Vista and install drivers for that device under 2003.

You can, however, install Virtual PC inside a hyper-v VM... . Not sure why you'd want to do it, but, it can be done.

The problem with this approach is it's inefficient usage of the underlying hardware, due to multiple levels of virtualization. It might be better to consider a hypervisor-based virtual server (assuming you have the Intel or AMD hardware to support such software) like Microsoft Hyper-V, Xen, or VMWare ESXi. This way your virtual server software is running in the hypervisor, and your VMs are running as close to the hardware as possible and still give you the ability to divvy up resources as needed.

Thanks DigeratiPrime, I had found that answer after some searching (now using VM server). What I don't understand, regardless of compatability issues, does it show different info for CPU etc? Because it's emulating the CPU you're using. Neither Virtual PC or VMWare Server (or workstation) are level 1 (hypervisor) virtualization products, which means they're level 2 and are virtualizing everything through the guest OS, including the processor and motherboard type, speed, chipset, etc.

Well, it looks like the FineCrypt .dll file is passing a bad heap value to the C runtime when a file is being accessed, causing an access violation and a crash: // You can see that ecx+50h results in 00000050, which is going to be invalid: 0:020> ~19s eax=0367aef4 ebx=0367ae68 ecx=00000000 edx=782bca1c esi=0367adf4 edi=00000085 eip=7822a761 esp=0367adac ebp=0367add4 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 mfc80+0x5a761: 7822a761 83795000 cmp dword ptr [ecx+50h],0 ds:0023:00000050=???????? // The stack - FCShell.dll is likely responsible for ecx: 0:019> k ChildEBP RetAddr WARNING: Stack unwind information not available. Following frames may be wrong. 0367add4 02843202 mfc80+0x5a761 0367af68 7e41882a FCShell+0x3202 7e41885a ff8b9090 user32!UserCallWinProcCheckWow+0x116 7e41887e 8d000002 0xff8b9090 7e418882 8e3b0448 0x8d000002 7e418886 00000000 0x8e3b0448 0:019> uf 0367af68 ... 0367af6a 67032a add ebp,dword ptr [bp+si] 0367af6d 88417e mov byte ptr [ecx+7Eh],al 0367af70 80eb09 sub bl,9 0367af73 006003 add byte ptr [eax+3],ah 0367af76 15008830b2 adc eax,0B2308800h 0367af7b 011400 add dword ptr [eax+eax],edx 0367af7e 0000 add byte ptr [eax],al 0367af80 0100 add dword ptr [eax],eax 0367af82 0000 add byte ptr [eax],al 0367af84 3857b4 cmp byte ptr [edi-4Ch],dl 0367af87 0180eb090000 add dword ptr [eax+9EBh],eax 0367af8d 0000 add byte ptr [eax],al 0367af8f 0000 add byte ptr [eax],al 0367af91 0000 add byte ptr [eax],al 0367af93 0000 add byte ptr [eax],al 0367af95 b067 mov al,67h 0367af97 0301 add eax,dword ptr [ecx] 0367af99 0000 add byte ptr [eax],al 0367af9b 0000 add byte ptr [eax],al 0367af9d 0000 add byte ptr [eax],al 0367af9f 0001 add byte ptr [ecx],al 0367afa1 0000 add byte ptr [eax],al 0367afa3 0070af add byte ptr [eax-51h],dh 0367afa6 670300 add eax,dword ptr [bx+si] 0367afa9 0000 add byte ptr [eax],al 0367afab 0000 add byte ptr [eax],al 0367afad b067 mov al,67h 0367afaf 038f04447e30 add ecx,dword ptr [edi+307E4404h] 0367afb5 88417e mov byte ptr [ecx+7Eh],al // The thread doing the lookup, which actually is throwing the exception: 0:020> kb ChildEBP RetAddr Args to Child 03d2ffb4 7c80b713 00000000 0367de60 0367de60 ntdll!KiFastSystemCallRet 03d2ffec 00000000 7c910230 00000000 00000000 kernel32!GetModuleFileNameA+0x1b4 0:020> ub 7c80b713 ... 7c90e4da e829000000 call ntdll!RtlRaiseException (7c90e508) 7c90e4df 8b0424 mov eax,[esp] 7c90e4e2 8be5 mov esp,ebp 7c90e4e4 5d pop ebp 7c90e4e5 c3 ret 7c90e4e6 8da42400000000 lea esp,[esp] 7c90e4ed 8d4900 lea ecx,[ecx] ntdll!KiFastSystemCall: 7c90e4f0 8bd4 mov edx,esp 7c90e4f2 0f34 sysenter ntdll!KiFastSystemCallRet: 7c90e4f4 c3 ret 7c90e4f5 8da42400000000 lea esp,[esp] 7c90e4fc 8d642400 lea esp,[esp] ntdll!KiIntSystemCall: 7c90e500 8d542408 lea edx,[esp+0x8] 7c90e504 cd2e int 2e 7c90e506 c3 ret 7c90e507 90 nop ntdll!RtlRaiseException: 7c90e508 55 push ebp 7c90e509 8bec mov ebp,esp // The likely culprit: 0:020> lmvm FCShell start end module name 02840000 02945000 FCShell T (no symbols) Loaded symbol image file: FCShell.dll Image path: C:\Program Files\FineCrypt\FCShell.dll Image name: FCShell.dll Timestamp: Tue Jan 08 15:10:18 2008 (4783D8AA) CheckSum: 0010F362 ImageSize: 00105000 File version: 10.1.0.1 Product version: 10.1.0.0 File flags: 0 (Mask 3F) File OS: 4 Unknown Win32 File type: 2.0 Dll File date: 00000000.00000000 Translations: 0000.04b0 0000.04e0 0409.04b0 0409.04e0

Have you considered using a rescue boot disk to reset the Admin password? Also, the behavior you speak of is *highly* suspicious - are you sure your box isn't infected with something?

If you have two scopes on the same network segment, there's no real way to segment the assignment short of using reservations. However, if you have two separate network segments used by these two scopes, you could put the DHCP server on it's own segment and use DHCP forwarders to do the job. However, if the DHCP server is on the same network segment as the machines you wish to segment, you will have to use DHCP reservations. The DHCP DORA process is UDP broadcast, and there's not really any way to keep certain machines on a certain scope in this configuration without MAC reservations.

Problem is that the user's profile (just the act of using winlogon to log on) locks index.dat in the user's temporary internet files, which won't be released until fully logged off. Therefore, a logoff script won't be able to fully delete the profile. This would work on a 2008 or Vista machine, but not a 2003 box. Consider using delprof.exe in a script run from an automated task when the machine is idle, say overnight, to delete profiles older than <x> days (or all profiles, whatever).

Since it seems no one saw this, I'll repost. Note that the 0x124 STOP error means the following: Thus, your 0x124 and parameters mean the following: 0x00000000 - This means the error came from the processor, and not an NMI or PCI-E error 0x8537A3B0 - The WHEA error record 0xB2000000 - The high 32bits of the MCA bank that reported the error 0x00010014 - The low 32 bits of the MCA bank that reported the error Obviously the last three parameters are not useful without a memory dump, but note that *all* WHEA errors are "Machine Check Exception" bugchecks, which means your hardware detected an error that it couldn't correct, so it sent an INT18 to Windows (and Windows then goes through it's routine to bugcheck with either a 0x124 on Vista or 0x9C error on Windows 2000, 2003, and XP). As always, start by running hardware and memory diagnostics - according to the hardware and Windows (not to mention your statement here), you do have a malfunctioning piece of hardware in that system, but without a dump we'll not be able to say what.

The 8E you're getting means a driver on the system attempted to write to an address that was specifically marked as read-only. I would only be able to suggest that you completely uninstall the ZyXEL software and drivers, and do a reinstall of an older known-good version. What was the reason for the upgrade, by the way?

Just note that the 0x124 STOP error means the following: Thus, your 0x124 and parameters mean the following: 0x00000000 - This means the error came from the processor, and not an NMI or PCI-E error 0x8537A3B0 - The WHEA error record 0xB2000000 - The high 32bits of the MCA bank that reported the error 0x00010014 - The low 32 bits of the MCA bank that reported the error Obviously the last three parameters are not useful without a memory dump, but note that *all* WHEA errors are "Machine Check Exception" bugchecks, which means your hardware detected an error that it couldn't correct, so it sent an INT18 to Windows (and Windows then goes through it's routine to bugcheck with either a 0x124 on Vista or 0x9C error on Windows 2000, 2003, and XP). As always, start by running hardware and memory diagnostics - according to the hardware and Windows (not to mention your statement here), you do have a malfunctioning piece of hardware in that system, but without a dump we'll not be able to say what.

Same. And I don't know why you don't wish to uninstall to test: 0:011> lmvm SSCtxMnu start end module name 02c70000 02ced000 SSCtxMnu (deferred) Image path: C:\Program Files\Spy Sweeper\SSCtxMnu.dll Image name: SSCtxMnu.dll Timestamp: Fri Jun 19 18:22:17 1992 (2A425E19) CheckSum: 00078464 ImageSize: 0007D000 File version: 5.5.7.124 Product version: 5.5.0.0 File flags: 8 (Mask 3F) Private File OS: 0 Unknown Base File type: 1.0 App File date: 00000000.00000000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 It is still loaded and running.

So some driver on the system, be it usbport.sys or another, is at an IRQ level of DPC dispatch or higher (IRQL 2 or higher, up to IRQL 31) and referenced a memory address which was either not valid, or was paged to disk. This is not allowed in Windows due to the fact that having to page memory in requires the IRQL to be 1 or 0, meaning you would not drop down to that level until the driver that caused the page fault (running at the higher IRQL) is finished doing whatever it's doing, which it can't until the memory data it requested is paged in.... you see the problem, deadlock. Thus, Windows bugchecks to let you know a driver did something bad, rather than just deadlocking and leaving you guessing . Anyway, we'll need a dump - if it's usbport.sys or another driver, we should see it in the dump.

It should work just fine. Windows Defender used to be Giant Antispyware, one of the best products out there (at the time it was purchased), and is part of Windows Live OneCare (a non-free product), which does quite well.

Well, that'd do it. If you uninstall that device from device manager and reboot, does device manager find anything new after the reboot? Also, what laptop is it? You can tell usually what video chip is in the laptop by make/model.

Personally using Windows Defender on Vista with no issues, all scans with major tools come up clean regularly. It does it's job, regardless of engine age (the engine is minimal).

http://money.cnn.com/news/newsfeeds/articl...ire/0432343.htm Apparently nVidia may actually have to pay for their failures, if a court agrees with the plaintiffs. Bias indeed.

Honestly, yes. I've tried a few different ways to "migrate" from x64 to x86, but none of them were very successful (purely educational endeavors). If this is going to be a system you want to rely on, yes, rebuild.

Honestly, it would be better, assuming you only want x86 XP, to format and reinstall rather than doing the above. If you can get an external storage device, or create a temporary partition to back up your data, this would be much better long term.

There could be a few reasons, but the easiest/best way to do this would be for you to configure a machine for a complete memory dump, and then compress the resulting .dmp file after the next bugcheck and upload it somewhere we can look at it.

I would suggest a virtual machine rather than a dual boot, if possible. You don't need to monkey with partitions, boot.ini files, nor do you need to worry about having to reboot to change environments.

Research WMI Filtering on group policies.