cluberti

Hard to say with 100% certainty, again, without the .dmp file. However, looking at the stack again I see that the last operation attempted was MiRelinkStandbyPage, which came as a result of PfSetSuperfetchInformation. What we don't see (because it we've not gotten there yet) is that this *should* (when it works) cause an MmCreateSection call, so mapping a file directly into a section of memory. The reason we don't see it is because it appears this failed at moving a memory page from the Standby list into the Ready pages list (which would then be able to be allocated to service the CreateSection call from the memory manager, further down the line). Given that it's failing during what would be an attempt to map pages (4k chunks) of RAM directly via the memory manager when there's a crash, you can be almost 100% sure this is a failure at the hardware level. I would suggest removing/reseating the RAM, making sure everything's had a once-over from a can of air, etc, and then run a memtest. Assuming the memtest passes after that, this should not occur any further. However, it does really look like you've got bad RAM (or a bad controller on the motherboard, although that likelihood is usually much smaller than simply a bad chip on a stick of RAM causing it).

This is a part of my blog post here.

It's been discussed here recently, in fact. Before install, and after.

Well, using the system from safe mode isn't exactly an everyday operation either, so I'm not sure it matters .

I believe this happens in safe mode because system restore status isn't accessible, so it's making a backup "just in case". The C:\System Volume Information\_restore folder is indeed the location for system restore, so you should theoretically be able to delete the contents of this folder without repurcussion if System Restore is indeed disabled for the system (don't delete the _restore folder itself, just it's contents).

I always find it interesting to look at market cap - if you factor in Apple's cash figures are missing their treasuries and their other liquid assets they're actually worth a bit less, but it'd still be nice to have that kind of market cap for sure .

This might be best run as an HTA which drives the WMIC calls from user input.

You really should be using the latest WAIK. You've got the Vista version installed - WSIM, for example, is 6.1.7600.16385 from the Windows 7 WAIK. Also, how are you integrating the hotfixes - via WSIM, or via dsim directly into the image?

Have you looked at a network trace to see what the SMB error was from the server (if any) when the user clicked Save As? If there's a permissions error and the folder is redirected, there should be SMB traffic that you should see when the save attempt is tried (perms should be checked to make sure the file can be saved).

TiVo is nice because the UI is pretty dead-simple, but on a feature-by-feature basis I think MCE is probably better. Both TiVo and MCE will allow multi-room viewing, although TiVo requires another full TiVo for it, whereas MCE can use an extender - depending on the quality of MCE extender, these can cost almost as much as a full TiVo though (although any PC or xbox with MCE can be an extender as well), so it's probably a wash. Ultimately, it's up to you (or maybe more accurately, your wife) as to which you want to use. I found the new TiVo premier units with HD to be quite good, but the ads were annoying enough that I ended up sticking with MCE. The one sticking point you have to watch out for though with TiVo is the monthly fee - you will pay said monthly fee for the use of it and it's guide data/updates, whereas MCE has no costs above and beyond the initial purchase price. However, the fee is pretty nominal (a few $ a month), but it is there (and if you don't pay the fee, TiVo stops getting guide data).

Notice if this ever happens to you in the future, the Process Explorer binary simply adds itself as an Image File Execution Option for taskmgr.exe here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe Just delete the taskmgr.exe key inside the Image File Execution Options key, and it'll stop trying to start procexp.exe. If you want to see what it does, Set Process Explorer as a task manager replacement, and then look in that registry location to see what it did. It's pretty simple, actually, but effective.

It doesn't tell you much more than what Trip mentioned. Without the accompanying .dmp file opened and analyzed in windbg or cdb, it's hard to say what. However, most of these are indeed caused by bad memory in a system, so testing isn't a bad idea for sure.

That requires GPMC or AD role tools to be installed, this does not . I'm not saying it's groundbreaking, but for a quick search it's pretty nifty.

Technically this could also go into the programming section, but it seems unattended-specific so placing this here.

If you're going to use flash/dvd, and you aren't using SCCM already, you might want to consider MDT. Also, MDT can use WDS to push it's boot images if you do get it working, so there's an easy migration path from flash keys / dvds to using PXE deployment.

I've used all 3 (and also MythTV), and TiVo is the most "user friendly". However, it's also a closed box with no other real capabilities, and it's pretty expensive for a decent version that can store large amounts of TV. I personally prefer using an OEM Windows 7 Media Center machine, and although I don't get the TiVo "suggestions" feature with MCE, I can't say I miss it either - I really only ever watched any suggestions when it didn't have anything left recorded from my to-do list, which was pretty rare. Also, with other internet TV providers and Netflix integrated into MCE, the media library from Zune, iTunes, and my Windows Home server also available to MCE and usable from other PCs or the 360 extender in the living room, I'm happy with my choice. You will need to do what's best for you, but even a TiVo is going to need CableCARD devices anyway if you want full cable programming. MCE will work with an external cable box with an IR device if you wanted to take an off-the-shelf PC and use it as an MCE, but if you want CableCARD support you need an OEM system with a specific BIOS extension to use the cards. I actually do the former (standard Win7 box, not MCE-specific) because I don't need CableCARD - everything I want to watch from TimeWarner comes in to a Slingbox HD Pro, which is connected to the MCE box with an ATI tuner inside via component in the office in a corner. I watch everything on extenders or a laptop or desktop elsewhere in the house, which works fine.

http://gps.cloudapp.net/

I'm currently using oscdimg.exe from the WAIK to make bootable ISOs, and then the inbox Win7 tool to burn them. Since pretty much every bootable disc I make is for some sort of install of Windows, it seems to be the easiest way to do it and be sure it works.

I generally sleep my laptops if it's going to be off for only a few hours, or up to a day. I've tested it and it takes a little over a week for a "sleeping" laptop to drain the battery on a Dell Studio 17, for what it's worth, but I wouldn't sleep a laptop for that long. If it's going to be off for more than just a few hours, I hibernate it as it is basically off. This is configured in the power options when I put a machine in S3 sleep - after 6 hours, it will automatically go to S4 (hibernate).

1. Unless the machine came from HP specifically as a Vista Media Center machine, you don't have a BIOS with DCT (it's still fairly rare). 2. Only OEM versions of Windows Vista Home Premium and Windows Vista Ultimate had an OEM-only hotfix that enabled the DCT feature, so the statement (while confusing) is accurate - you need either Windows Home Premium, or Windows Ultimate - either must have the DCT patch (the sentence you found is proper English, but can be a bit confusing if you think too hard). I would add a 3: 3. Get a Windows 7 Media Center machine from an OEM (either HP or Dell will have them readily on hand - most other OEMs don't even make them) with CableCard support if you're going to get CableCARD - considering #1 here and the fact you most likely don't have a DCT BIOS, getting a Win7 MCE machine might be your best option (MCE in Win7 is quite a bit better than MCE on Vista in a few CableCARD specific areas too, like, oh, stability).

No worries, I ended up going with a COM module - it's not great, but it was pretty easy to do. I have to use WSF because the admins at the site who will be maintaining it are not high-level and this is about as much "code" as they can handle, so it must be easily template-able and easy to understand for folks coming from an all-W2K network (powershell is out - they just glazed over when I started to talk about it, so I knew WSF was the way to go with these guys). The COM object is kinda nice though, as I can call it from any script, anywhere (including PS). If I get it to where it's not such a hack job, I'll throw it up in the code repository.

I've never had issues with it, but then again I avoid upgrading OSes like the plague. Sorry to hear you gave up, but rebuilding would have saved you ~3 weeks . The WDS logs probably would tell you what's wrong as well. Did you try enabling those?

The 6.1 RDP client update doesn't update the underlying encryption methods, and Network Level Authentication (needed to connect to a Vista or Win7 machine by default) only exists in Windows XP SP3, Vista, and Windows 7. Given it's not working, it sounds like you're using Windows 2000, a version of XP less than SP3, or you haven't enabled CredSSP access yet on your XP SP3 system as per KB951608). If you are using XP SP3, it would be wise to enable CredSSP access (it's a more secure way of setting up and connecting to another RDP host) as per the linked KB article. If you want to see if a client supports using CredSSP (and thus will use NLA to connect to another RDP host), open the RDP client, right-click the window title bar, and select "About" - it should say "Network Level Authentication supported" in the About dialog box.

Logging is a pretty big part of any script, and I'm trying to standardize this for a whole slew of WSF files run in an environment. I'm trying to move all of the logging functions out of the main script and into a .vbs or .js that I can then just <include> in the WSF itself, but creating something that persists like a log file in an include seems almost impossible. Anyone have any ideas? Logging of course is easy to do in the body of the main script (and does work fine), but I'm trying to move repetitive things out of the bodies of my main WSF files and into included JS or VBS files for two reasons - one, script re-use and standardization is nice, and two, it saves time if I can simply call a function to create a log file or write a line to an open file. Given the way includes work in WSF files, however, I'm not sure how feasible this is. I can create a log file without issue, but going back and simply writing to it has been the chore. Soooo.... any ideas?

Agreed - OP, if you want scripting help, please post the script you want help with.