Mr Snrub

Bleh, I'll never be as good technically or pedagogically as Mark Russinovich, but let me have a stab at this misconception:A mix of terminology there - drivers run in kernel mode, services run in user mode. "Code" does not execute - threads do - and that is not semantics, there is a vast difference between processes using virtual memory by their presence/size and the number of threads in the READY state. The working set of a process is that subset of its virtual size which is actually using physical memory - that is a more useful measurement of load on system resources. A high number of threads in the READY state at any given time would indicate a bottleneck with the processor(s) - but system initialization is where there will be a lot of competition for all kinds of system resources so is not a good yardstick for comparison. The number of entries in the process list does not give any indication of "bloat" or work the system actually has queued. e.g. "There are more svchost.exe process in Vista than in XP, slowing down or bloating my system!" Vista has added more features and resulted in the creation of new services, and previous large services may have been split into multiple ones to make them more modular or fit the changed (extended) security model better - the aim being to only give the services the permissions they need (think back to when everything ran as "SYSTEM" and the risk that poses). Actually, efficiency comes in many different forms - preloading data from a relatively very slow storage device (disk) into one of the fastest volatile storage locations (RAM) is a way to gain efficiency by reducing (or eliminating) delays when the data is demanded.One of the big changes that made XP appear faster than 2000 was the parallelization of some processes - you get to the desktop quicker and can "start working", but in reality the system is still completing its startup routine (whereas on 2000 you didn't get the logon prompt until those processes had completed in a serial nature). Vista introduced the delayed auto-start service type too - to allow the much more vital automatic services to get CPU time and disk access first, before using the resources later instead of competing for them - for efficiency. At the very lowest level, it can be more efficient to have longer code instead of a tiny "loop" due to the lower number of jumps in the instruction pointer which wastes CPU cycles - the result is larger binaries on disk and bigger memory footprints... for more efficiency at runtime. Some of the enemies of efficiency is compatibility, stability, security and flexibility: - making product version X+1 work with products designed for product X - checking the data being processed and assumptions are not made (e.g. data integrity & preventing crashes due to corrupt data) - checking the data being processed falls within boundaries (e.g. prevent buffer overrun exploits) - making sure the product allows for future expansion without a rewrite from scratch An OS can never be about only efficiency. Of course! Everyone is entitled to opinions, and it's always interesting to read peoples' perceptions.

When is the message presented? - every time you launch a particular program? - at random? - every X minutes if there is no DHCP lease on the client? - after starting Windows it pops up once at the beginning of the session? Have you tried disabling the WebClient service as a test? You could use Process Monitor to see what processes are checking for those registry values you created, it might give some clues...

Are you using F6 to supply disk controller drivers during install? Have you gone through the steps on Advanced troubleshooting for "Stop 0x0000007B" errors in Windows XP that relate to OS installation? Have you tried configuring your SATA compatibility as IDE in the BIOS?

Is this at startup or at logon? (Or maybe you have autologon so you go straight to the desktop so you can't tell?) AutoRuns is your friend I think - you will have an entry whose Image Path is just the string "S" somewhere. I would look on the Logon tab first, it's a much smaller list.

Do you mean that you have 1 specific Visio file that you can't open, or the Viewer reports that for any file? Does the file open on other PCs without a problem? [moved to correct forum]

http://www.msfn.org/board/Forum-Rules-Upda...ead-t18408.html Your question appears to be related to unattended installations (and may need a little more information to be answered) - forwarding to the right forum.

5. Using Process Monitor Process Monitor (ProcMon) is a great tool for recording I/O-related activity on Windows - effectively a combination of the old RegMon and FileMon tools plus extra information such as process and thread creation and exit. It will not show you inter-process activity, and in the case where files exist but contain garbage there will be no error to track, so it's not guaranteed to uncover all types of causes for program failures. It is of particular use for situations where applications fail to launch if it is due to an "access denied" or "name not found" error when a process accesses specific registry or file resources. It can also be useful for logging boot or logon activity (under Options / Enable boot logging) - on launching ProcMon after rebooting and logging on you can save the log produced for analysis. It is recommended to use it for recording data with the default filter, and afterwards use display filters to focus on the I/O you are interested in. Due to its nature, the system will run significantly slower while ProcMon is recording activity - keep the recording sessions as short as possible and have all unnecessary applications (and notification area processes) stopped. You may want to consider stopping anti-virus during the recording session too, as it will generate more I/O and slow the system down further. Bear in mind that "name not found" and "path not found" results may be normal - applications may check for the existence of certain resources in order to determine what they should do - a comparison with a ProcMon trace from an identical working system may be more productive in these situations. "Buffer overflow" is also normal when reading from the registry - this is a probe to find out how large the item is before allocating memory and then requesting the data again. ProcMon also records the stack of the thread for each log entry, and optionally use debugging symbols (with the help of dbghelp.dll from the Debugging Tools for Windows) to record more detailed function information. It does not use the _NT_SYMBOL_PATH variable, the symbols path must be configured separately as well as specifying the location of dbghelp.dll via Options / Configure symbols. The path for dbghelp.dll by default would be one of the following, depending on the verison of Windows: C:\Program Files\Debugging Tools for Windows (x86)\dbghelp.dll C:\Program Files\Debugging Tools for Windows (x64)\dbghelp.dll The symbols path can be configured in a similar way to _NT_SYMBOL_PATH, e.g. %systemroot%\SYMBOLS*http://msdl.microsoft.com/download/symbols After configuring the symbols options, ProcMon needs to be restarted - then you can verify they are resolving correctly by double-clicking a log entry to view the details and click the Stack tab - in the bottom left corner it should read "Loading symbol module for xxx..." for each module in the stack, from top to bottom (this can take a while). As each symbol module loads, the stack display updates the "Location" field automatically to provide more detailed information for Microsoft modules for which there are public symbols available for the version in use.

I'm not a fan of "tweaking guides" as Windows is used in different ways by different people and it's very difficult for users to determine what services they don't need - either right now, or in the future after installing WhizzBang Application X v3.0 which mysteriously fails to install or run for no apparent reason. I've had a look at the ProcMon log but... ew... managed code :s Not my speciality. I think the exception handler kicks in after the font substitutes have been enumerated but I can't make a whole lot of sense as ProcMon only records I/O and this could be a failing in inter-process communication... This is event 396156, where it looks like the exception handler is getting ready to throw: 0 fltmgr.sys FltpPerformPreCallbacks+0x28a 1 fltmgr.sys FltpPassThroughFastIo+0x6a 2 fltmgr.sys FltpFastIoQueryOpen+0xef 3 ntoskrnl.exe IopParseDevice+0xb85 4 ntoskrnl.exe ObpLookupObjectName+0x5eb 5 ntoskrnl.exe ObOpenObjectByName+0x2f4 6 ntoskrnl.exe NtQueryAttributesFile+0x134 7 ntoskrnl.exe KiSystemServiceCopyEnd+0x13 8 ntdll.dll NtQueryAttributesFile+0xa 9 ntdll.dll RtlDoesFileExists_UstrEx+0xad 10 ntdll.dll LdrpSearchPath+0xbd 11 ntdll.dll LdrpCheckForLoadedDll+0x1e3 12 ntdll.dll LdrpLoadDll+0x162 0x77895af2 13 ntdll.dll LdrLoadDll+0x136 0x77895836 14 kernel32.dll LoadLibraryExW+0x15e 15 mscorwks.dll Thread::UserSleep+0x139 16 mscorwks.dll CLRLoadLibraryEx+0xb6 17 mscorwks.dll DoPreloadLibraryThrowing+0x152 18 mscorwks.dll CorDelayLoadHook+0x1e 19 mscorwks.dll _delayLoadHelper2+0x1e3 20 mscorwks.dll _tailMerge_VERSION_dll+0x3f 21 mscorwks.dll GetFileVersionInfoSizeW_NoThrow+0x5c 22 mscorwks.dll DwGetAssemblyVersion+0x6f 23 mscorwks.dll GetManagedBucketParametersForIp+0xf5 24 mscorwks.dll GetBucketParametersForManagedException+0x3f 25 mscorwks.dll Thread::ReturnToContext+0x356 26 mscorwks.dll GetResourceStringFromManaged+0x1f0 27 mscorwks.dll GetResourceFromDefault+0x139 28 mscorlib.ni.dll mscorlib.ni.dll+0x34c332 29 mscorwks.dll CallDescrWorker+0x82 30 mscorwks.dll CallDescrWorkerWithHandler+0xe5 31 mscorwks.dll MethodDesc::CallDescr+0x306 32 mscorwks.dll InvokeUtil::CreateTargetExcept+0x1da 33 mscorwks.dll `string'+0xa044c 34 mscorwks.dll RuntimeMethodHandle::SerializationInvoke+0x221 35 mscorlib.ni.dll mscorlib.ni.dll+0x2e744d 36 mscorlib.ni.dll mscorlib.ni.dll+0x2dc3a0 37 mscorlib.ni.dll mscorlib.ni.dll+0x2dc4e6 38 mscorlib.ni.dll mscorlib.ni.dll+0x2dc723 39 mscorlib.ni.dll mscorlib.ni.dll+0x19cd0b 40 mscorlib.ni.dll mscorlib.ni.dll+0x1aca66 41 mscorlib.ni.dll mscorlib.ni.dll+0x28f729 42 mscorlib.ni.dll mscorlib.ni.dll+0x28fe1b 43 mscorlib.ni.dll mscorlib.ni.dll+0x2904f3 44 mscorlib.ni.dll mscorlib.ni.dll+0x28e6dc 45 mscorlib.ni.dll mscorlib.ni.dll+0x28e75d 46 System.ni.dll System.ni.dll+0x2d62e5 47 System.ni.dll System.ni.dll+0x2d61e6 48 System.ni.dll System.ni.dll+0x2d64a0 49 MIGUIControls.ni.dll MIGUIControls.ni.dll+0xe16c2 50 MIGUIControls.ni.dll MIGUIControls.ni.dll+0xe1eda 51 MIGUIControls.ni.dll MIGUIControls.ni.dll+0xe2ca2 52 TaskScheduler.ni.dll TaskScheduler.ni.dll+0x6ba7 Did you make any changes to COM+ or DCOM at all? Edited stack from event 396395 - not sure if "RealCOMPlusThrow" is a possible cause or simply a symptom: 63 kernel32.dll RaiseException+0x39 64 mscorwks.dll RaiseTheExceptionInternalOnly 65 mscorwks.dll RaiseTheException+0x57 66 mscorwks.dll BStrFromString+0x66 67 mscorwks.dll RealCOMPlusThrow+0x35 68 mscorwks.dll RealCOMPlusThrow+0xb 69 mscorwks.dll `string'+0xa2724 70 mscorwks.dll CrossDomainChannel::ExecuteCrossDomainCall+0x59 71 mscorwks.dll CrossDomainChannel::CheckCrossDomainCall+0x100 72 mscorwks.dll CTPMethodTable::OnCall+0xd4 73 mscorwks.dll TransparentProxyStub_CrossContext+0x64 74 MMCEx.ni.dll MMCEx.ni.dll+0x3a509 75 mscorlib.ni.dll mscorlib.ni.dll+0xa9710 76 mscorlib.ni.dll mscorlib.ni.dll+0xeeacf

4. Memory dump options for Windows XP USER-MODE (APPLICATION) MEMORY DUMPS For applications that hang or crash, the Debugging Tools for Windows are the easiest way to obtain a memory dump to analyze: Debugging Tools for Windows - Overview http://www.microsoft.com/whdc/devtools/deb...ng/default.mspx 1. Open a command prompt and change the working directory to where you installed the Debugging Tools for Windows Commands to switch to the default folders depending on the version of Windows installed: 32-bit: cd "\Program Files\Debugging Tools for Windows (x86)" 64-bit: cd "\Program Files\Debugging Tools for Windows (x64)" Determine first if the application is crashing ("this program has encountered a problem and will be shut down") or hanging ("not responding"): For CRASHING applications: 2. Enter the following command to attach to the running process MYAPP.EXE (replace as appropriate) which will crash: adplus -crash -ctcf -pn MYAPP.EXE -quiet -o C:\AppDumps > Whilst waiting for the process to crash you will see a minimized cdb.exe process 3. Wait for the application MYAPP.EXE to crash (or reproduce the crash if possible) > A unique folder will be created in C:\AppDumps with the dump file and some .TXT files containing process & thread information > The minimized cdb.exe window will close when it is done For HANGING applications: 2. Enter the following command to attach to the hung process MYAPP.EXE (replace as appropriate): adplus -hang -ctcf -pn MYAPP.EXE -quiet -o C:\AppDumps > A unique folder will be created in C:\AppDumps with the dump file and some .TXT files containing process & thread information > The minimized cdb.exe window will close when it is done > The MYAPP.EXE process is not terminated VISTA / SERVER 2008 NOTE: On Windows versions later than Server 2003, the method for getting a dump of a hung process is much easier and does not require the Debugging Tools to be installed - simply start Task Manager, switch to the Processes tab, right-click the process that is hung and select Create Dump File from the context menu. Once the dump process is completed you are informed as to where the file was created. KERNEL-MODE MEMORY DUMPS By default, Windows XP only creates "minidumps" a bugcheck (bluescreen) occurs - this is 64KB and contains almost no information to help with a good analysis. The OS needs to be prepared to produce the right level of detail when bugchecks occur - "kernel" or "complete" dumps. Kernel dumps will be smaller, but do not hold any information from user-mode space. Complete dumps contain kernel and user-mode memory and can be considerably larger. Most of the time kernel dumps are enough to perform good analysis of a problem, and as they are smaller they are quicker to produce and to upload/download. A memory dump from the OS is created in PAGEFILE.SYS on the boot volume (typically C:) during the time the STOP screen is displayed, along with "beginning dump of physical memory". Windows then restarts and the dump is copied from C:\PAGEFILE.SYS into a separate file, defaulting to C:\WINDOWS\MEMORY.DMP. Because the page file on the boot volume is required, it must exist and have its initial size large enough to guarantee a successful dump: KERNEL (32-bit): physical RAM plus 50MB up to a maximum of 2098MB KERNEL (64-bit): physical RAM plus 50MB COMPLETE (32-bit and 64-bit Windows): physical RAM plus 50MB Additionally you need at least the same amount of free disk space on the boot volume to guarantee that MEMORY.DMP is created. To check the page file settings: - Click the Settings button under Performance - Click the Advanced tab - Click the Change button - Check the page file on the boot volume is large enough, as per the paragraph above To prepare the system to create a useful memory dump the next time it bugchecks: - Right-click My Computer, click Properties - Click the Advanced tab - Click the Settings button under Startup and Recovery - Under Write debugging information, select Kernel memory dump or Complete memory dump as required For situations where Windows is hanging (rather than crashing), if you have a PS/2 keyboard connected then you can configure the system to bugcheck on demand by creating the following registry value via RegEdit (then reboot afterwards): To bugcheck the system, hold down the right-hand CTRL key and press SCROLL LOCK twice. VISTA / SERVER 2008 NOTE: On Windows versions later than Server 2003, the dump options are configured in the same place, but to get there you right-click Computer on the Start menu rather than My Computer on the desktop, and click Advanced System Settings in the left pane. NEED SOMEWHERE TO UPLOAD A DUMP FILE FOR ANALYSIS? SkyDrive is a free Live service providing 5GB of online storage. It is also recommended to compress the dumps first, using something like 7-zip.

You need to prepare your system to create a kernel memory dump the next time it bugchecks (bluescreens): - Right-click My Computer, click Properties - Click the Advanced tab - Click the Settings button under Startup and Recovery - Under Write debugging information, select Kernel memory dump - Click OK - Click the Settings button under Performance - Click the Advanced tab - Click the Change button - Ensure that the drive on which the Windows folder resides (the 'boot' drive) has a page file at least as large as the RAM you have installed plus 50MB (e.g. if you have 1GB RAM on a default installation, the page file needs to go up to at least 1074MB on the C: drive - if the range already covers this then no change is required) - Click OK on each of the 3 open windows When the system next bugchecks it will display a status message "Beginning dump of physical memory" and work up to 100% before restarting. After restarting, the memory dump is copied from %systemdrive%\pagefile.sys to %systemroot%\MEMORY.DMP. Zip up the MEMORY.DMP file and upload it to any of the free file sharing sites and post a link here so we can download it for analysis.

Shooting from the hip time You're running the W2K3 SP2 (GDR) kernel - I don't know if your system or SQL is particularly registry-intensive, but you may be experiencing the symptom from http://support.microsoft.com/kb/935926 : "A Windows Server 2003-based computer stops responding when the registry is in heavy use" The latest (QFE) version of the kernel I could find (which includes the above hotfix and others) is available to the public here - http://support.microsoft.com/?id=954337 : "The computer could potentially have problems if DPC routines are executed at an IRQL that is greater than DISPATCH_LEVEL in Windows Server 2003" Without a dump this is of course pure speculation

A search in Registry Editor brings up a modal dialog box while it waits for the thread spawned to return a result (or report it reached the end of the registry) - I could well imagine that if multiple threads were spawned to search (different parts of the registry) simultaneously then it would cause havoc with synchronization objects - what happens if they both get a hit at the same time, which would be displayed and what happens to the other result? Not all processes benefit from multi-threading, but "Windows" most definitely is SMP-capable.

If you run mmc.exe itself, does it launch okay? If so, does the error get displayed if you: - click on File / Add or Remove Snap-in - scroll down to Task Scheduler and double-click it - click OK with "Local Computer" selected - click OK Are there any other MMC views that fail with a similar error?

Did you install from original media, or was it vLited? The error message looks possibly .NET-related - did you remove any .NET Framework 2.0 components, or disable any services by any chance?

On Windows Server 2003: If the service is exiting abnormally (crashing) then you can use the Recovery tab on the properties of the service, you can specify an action for first failure, second failure and subsequent failures from: - Take No Action - Restart the Service - Run a Program - Restart the Computer The typical setup would be to select Restart the Service, but if you're having frequent/regular crashes then it would make more sense to fix the cause rather than workaround the symptom. In terms of being notified when the problem occurs, you could use something like BLAT to send an email from the command line via the "Run a Program" entry. Tip: If you want to send an email or SNMP trap via "Run a Program" AND attempt to restart the service, then you can create a batch file to run "net start servicename" after sending the alert. I've used the batch file with BLAT & NET START solution a few years ago to good effect for NLB web servers, as NLB is not application-layer aware and will still try to send (e.g. HTTP) connections to servers where the IIS service is not running but the server itself is up. This is for a "per-service, on-failure" solution - if you want a periodic health check of numerous services then cluberti's suggestion makes more sense : you could parse the output from "SC QUERY" for specific services and check the STATE field is RUNNING for those, or probably use WMI in a neater solution.

If you bring the Start menu up and then hit ALT-PRTSCR, then open Paint and paste the contents in there - it should be just the active window and not the entire desktop, making the image (and hence size) smaller. JPG format should be the smallest you can make it (in Paint on XP) I think. You can do the same (ALT-PRTSCR, paste into Paint) for the Properties pages and save those as separate files too, so we can verify the settings you have configured.

Workstation versions (i.e. 2000 Professional, XP, Vista) are licensed for 1 user session at any given time (so Remote Desktop'ing kicks the user off the console and attaches to the existing session).Server versions (2000 Server, Server 2003, Server 2008) are licensed for 1 console session + 2 Remote Administration sessions concurrently out of the box (more than that requires TS Licensing and Terminal Services to run in Application Mode).

Is the screensaver set to require a password on unlock, maybe?

Any pen-testing tools on the Internet will be testing the ports on your public IP address, which in your case is your router, not your computer (so long as you have not put your computer into the "DMZ")."Closed" is just as good as "Stealth", don't be concerned by the sensationalist garbage Mr Gibson spouts - but if it bothers you then the router config is what you should be looking at. Replacing the XP firewall with another would be pointless and gain you nothing.

Those folders are usually created on the volume with the highest % free disk space, and should be tidied up after the reboot - however "unclean" shutdowns or startups, or anti-virus programs may cause the folders to be left behind. To double-check there are no references to the folders, I rename them by adding a .TMP extension and making sure nothing is broken, then delete them a few restarts later.

If you've already identified that the problem is caused by LooknStop, then any diagnosis being done from an application cannot give you more information - all it can do is to confirm that it's not able to establish a connection. To be honest, if you're behind a NAT router then almost all of the features that most host firewalls provide are obsolete as you won't be seeing unsolicited traffic for it to filter, unless you put the machine into the DMZ of the router (bad, bad idea). I can only suggest contacting the support people at http://www.looknstop.com/ and seeing what they recommend - they may have it as one of their commonly reported problems and can give you a quick solution.

Was NIS and Spybot loaded after the rebuild, before the Windows updates were installed?Did you look to see what updates were actually downloaded, were there any device driver updates for example? Was the system RTM at first, then SP1 was one of the updates, or was it SP1 from clean?

Nope, it's nothing to do with where the installer was run from.Your problem is almost certainly as twig123 has said - you have some software installed which has installed some filter driver related to CD/DVD drives (burning software, Daemon Tools, ISO mounting software, etc.) and it doesn't work with SP3.

The registry hives are just databases and contain machine-specific data, so they may well be created from scratch during setup rather than have a template copied from the installation media. The versions of the files originally created during setup are copied away into %systemroot%\Repair: SECURITY, SOFTWARE & SYSTEM This is how one method of emergency recovery can be done, in the event of registry corruption you can copy one or all of these hives back into %systemroot%\system32\config from a recovery console (or when booted from another OS).

Actually one of the drives for Vista is energy saving - it goes to sleep after a period of inactivity, and the suspend-to-RAM just draws enough current to keep the contents of the memory chips intact while the mains is connected (no fans to run, no display to drive, no hard disks spinning).It's the next step up from hibernation (dumping memory contents to a file on disk that is read on resume) and is much quicker both in suspending and resuming. Sleep > Hibernate > Shut Down Beats having to mess about speeding up the boot process - I only reboot once a month (patch Tuesday) unless I need to physically move the PC or turn the mains off. Very handy being able to tap a key and have the logon prompt up in 2 seconds, check email and then put the machine back to sleep before heading to work in the morning.