cluberti

D1 bugchecks in netio.sys and tcpip.sys are almost always caused by an NDIS filter driver or the network card driver installed on your machine - are you using any firewall software, or other filter (like netlimiter)? Or, perhaps, nvidia drivers for the network card? I've seen both types of drivers and that one package cause lots of D1's on Vista.

It depends on how many domains are supporting users in the Exchange domain. It's not normal, specifically, but it is supported as far as I am aware.

Is there anything in the system event log that would correlate to this error?

Areas of concern: What is this? R0 - HKCU\Software\Microsoft\Internet Explorer\Main,Start Page = http://www.8757.com/ Known malware: O4 - HKLM\..\Run: [mClubclient.exe] C:\WINDOWS\system32\mClubclient.exe Spyware: O16 - DPF: {072039AB-2117-4ED5-A85F-9B9EB903E021} (NowStarter Control) - http://www.clubbox.co.kr/neo.fld/NowStarter.cab

(sorry, geek - gotta do it) Obligatory response to geek's BSOD comments.

I guess it's crazy some people will pay for ease of use and interoperability with their pre-existing components j/k

If there are trusts between domains, machines added to one domain will see the other trusted domains in the drop down box (along with the machine name). You may not actually be able to log into another domain, mind you, but it'll show up in the list .

Yeah, that's what I meant by "There's no going back (easily)" in my previous statement. Most of the Microsoft application data can move, like .pst files, favorites, etc - you just can't use USMT to do this unfortunately.

This is not possible - Vista's profiles are v2, and XP (and down) are v1. There's no going back (easily) once you've migrated.

That error means "VSS_E_VOLUME_NOT_SUPPORTED", and it's coming from VSS. Are you doing a clean install or an upgrade? If you're doing an upgrade, it's trying to back something up on a filesystem not supported, likely.

I'm sure you'll get lots of responses here (and all good ones), but my personal approach to a problem is: 1. Gather basic information about the problem, like when did it start, what changes were made on or about that time, what steps do you take to make it happen exactly, etc. 2. See the problem first-hand, if possible - gather any and all data regarding the problem including error messages, Dr Watson or adplus dumps of the process crashing, hanging, or using high CPU (if that is what is happening), gathering event logs, hardware information, etc. 3. Search knowledge bases like the Microsoft KB, Google/Live Search, etc. for similar problems reported and fixes (eventid.net is your friend if you find something salient in the event logs) 4. Reduce the problem configuration to the bare minimum components necessary to reproduce the problem, if possible, to save from troubleshooting incorrectly if at all possible (run autoruns and shellexview to disable anything non-Microsoft, boot in safe mode or safe mode w/ networking, remove hardware not necessary to run the machine, reseat all cards and memory sticks, remove all USB/firewire peripherals, etc.) It's a start .

Explorer crashing is never random - it's almost always either a shell extension or your video driver. Have you tried booting in safe mode to see if it happens there?

Better way to set the default folder view for all folders (undocumented, it seems). Note that I've seen these work on XP, 2003, and Vista/2008, but not on 2000 as I have no more 2000 boxes to play with and don't care to build a VM just to test this . These settings are per-user only, and configuring the following registry values in a user's profile will set the default view for newly created folders (in this example, the default will be the "detail" view): Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell Value: WFlags Type: REG_DWORD Data: 0 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell Value: Status Type: REG_DWORD Data: 0 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell Value: Mode Type: REG_DWORD Data: 4 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell Value: vid Type: REG_SZ Data: {137E7700-3573-11CF-AE69-08002B2E1262} Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags\AllFolders\Shell Value: WFlags Type: REG_DWORD Data: 0 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags\AllFolders\Shell Value: Status Type: REG_DWORD Data: 0 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags\AllFolders\Shell Value: Mode Type: REG_DWORD Data: 4 Key: HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags\AllFolders\Shell Value: vid Type: REG_SZ Data: {137E7700-3573-11CF-AE69-08002B2E1262} Here are all of the possible “mode” and “vid” values that can be set: Name Mode VID Icons 1 {0057D0E0-3573-11CF-AE69-08002B2E1262} List 3 {0E1FA5E0-3573-11CF-AE69-08002B2E1262} Details 4 {137E7700-3573-11CF-AE69-08002B2E1262} Thumbnail 5 {8BEBB290-52D0-11D0-B7F4-00C04FD706EC} Tiles 6 {65F125E5-7BE1-4810-BA9D-D271C8432CE3} Filmstrip 7 {8EEFA624-D1E9-445B-94B7-74FBCE2EA11A} Delete the following reg keys to get rid of currently stored data, so that these folders also get the above settings: HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\Bags HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\BagMRU HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Bags HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\BagMRU

Are you using the built-in BIOS for the RAID card to create the array?

If you have the dump file on your machine from that crash, install the debugging tools from windows, open that crash dump in windbg, and run "!lmi 0x82461881" to see what's at that address (should tell you the driver that is at fault, unless it's the kernel - at which point further investigating should be done). I also apologize I haven't finished review of your other dump from another post - I ended up traveling for work and have forgotten even where I placed the file at this point .

If your exception list is that long (and in need of growing further), it's time to consider a proxy appliance or filtering firewall to do the job at that point. The IE exception list is limited due to memory size limitations on the storage of the exception list array, if memory serves. There won't be a way (at least in current versions of the browser) to bypass that limitation that I am aware of (perhaps someone else has achieved this another way?).

Another important skill when doing PC work is knowing when you don't know what you're doing - you need to know where to look to find things you need assistance with, yes, but also knowing when you've reached your limits and need to search or ask others is just as important as implementation. Don't assume you can always "figure it out" easily, and definitely don't learn something new on the customer's dime if there's the possibility you could make things worse .

So, this means in your case: STOP: 0x000000C5: 1. 0x00000000 - Memory address referenced was 0x0, and obviously this will cause a bugcheck (0x0 == NULL) 2. 0x00000002 - IRQL was DPC dispatch level, which means that an attempt to access an invalid (or paged out) memory address at this IRQL (2) will cause a bugcheck 3. 0x00000001 - It was an attempted write operation by a kernel-mode device driver 4. 0x82461881 - This is the address in memory of the device that attempted to do the write - if you have a dump from this, we may be able to run !lmi against this address to get symbols for who was here, or try and track back the stack and see how we ended up with 0x0 as the parameter for the memory address to reference.

It would have been nice to see !irp 84ebd7b8 and !devobj 856123d0, but !analyze -v did tell us that devobj 856123d0 is associated with bcmwl6.sys, which is likely the broadcom wireless NIC driver causing the problem (not surprised at all, either).

Description: VBscript subroutine to run elevated on Vista/Server 2008 when UAC is enabled. Programming Language: VBScript Usage: When a VBScript needs to run on Vista/Server 2008 and access parts of the system UAC protects when UAC is enabled, the script will simply fail. However, after calling this subfunction from your script, UAC will prompt when the script is run, and the script will continue once UAC elevation is allowed. Note that this also works on 2K3/XP when the user running the script is a non-Administrative user (a runas dialog will appear instead of a UAC prompt, obviously, but otherwise the same principles apply). VBScript_RunElevated.vbs.txt

No, I've read the links posted here. However, there's a lack of information on just how this occurs on a WSUS server, and specifically, how it was configured. I see a lot of "it happened automatically and I don't know why" responses, but nothing of substance with a "this one was configured this way, and it happened, and this other one was configured the same way and it didn't". I'm looking for that - otherwise, I cannot say for sure that it's something that's necessarily broken. I DID see that there were some people on slashdot who did admit that they had the "auto-approve updates for previously approved updates" selected, and had 2.x or 3.x already approved previously - and of course, this is an update so it auto installed. That I would expect (it's probably not good, but technically expected behavior). If that isn't the case, it's more likely that the previous versions were not declined but left to manual or not approved (the default), and the download for some reason auto-approved the update (which is an update and a full version, because WDS updates are just installers for that particular version). Again, I'm not saying it isn't broken, but there are a few scenarios that can cause this on WSUS and I'm not going to blame the package... yet. Edit: It does appear that the auto approve new revisions has something to do with it, mentioned on the blog.

That is correct, you cannot VPN into a network running the same IP addressing scheme as your own, otherwise routing fails completely (which is why you see that changing the IP range on the client resolves the issue). Sometimes this can be avoided via static routes and breaking up one subnet or the other into smaller subnets, but that's a pain and easily avoided if you set your domain network config differently than you expect clients to use. To this end, you should try to use nonstandard private ranges when setting up networks (like 10.200.x.x or 172.29.x.x instead of 192.168.x.x), because most home routers default to a subnet in the 192.168.x.x range. This will save you much trouble in the future - and reconfiguring your domain network to a nonstandard private subnet like 172.29.x.x or 10.200.x.x if you're using DHCP for clients and static IPs for servers is very easy and should only take a few hours of downtime to change over and get up and running again.

I would actually suggest against it - depending on how many users you have using the filesystem and how your folder structure is laid out, you can bring the processors in that server up to 100% continuous utilization just by enabling it. It is useful, I suppose, but most filesystem layouts are not optimal for it (you need small folder structures with very few subfolders, and very few numbers of files in each folder, otherwise bye-bye server performance ). I would suggest netmon or wireshark to gather data on the wire.

If you've got WSUS, this should not have happened, and I've not seen it on any of my domains. I'm not denying it's possible things are broken, but it seems more likely (at least at this point) that a configuration issue caused the approval and distribution of the update automatically.

Cool - further questions, just ask.