cluberti

CBS.log might be useful, as would all of the logs in \panther.

They probably have a volume license for Windows plus the additional Software Assurance included, which in general pays for a license for the latest version *or* the ability to install previous supported versions during their support lifecycle (XP x64 is still within it's extended support lifecycle, and thus would be installable if the enterprise VL agreement includes the Windows license + Software Assurance). It's the right to a license for Windows, just not a specific version. So yes, they've bought a license for Windows for something they won't install - however, it wasn't done specifically that way.

My original statement stands - on older hardware you are *not* going to actually *see* any real improvement. It is all under the hood.

If you are looking for UI improvements on such old hardware, you will be disappointed. There is much improved in dwm/aero, the kernel memory manager, stability, etc. The only real differences you would see with your eyes are not going to really be there on old hardware, so I am not surprised by your statement/questions.

It is coming from winerror.h.

That is true, although if your DHCP server is 2008 or 2008 R2 and the DHCP zone is AD-integrated, this should no longer happen.

Technically 1503 is an informational event, but yes, you still want some data. You can find information on how to enable debugging in userenv here, from Microsoft. That would be the place you'd want to start to figure out the "why" behind that 1503 for starters.

Correct - we have in the past heavily optimized and modified our installation of IPB to suit our needs, and as such we just don't deviate from the defaults if and when possible for the sake of compatibility with as much of the default IPB codebase as we can - this eases support issues and also makes it easier to make changes as necessary (when you know your baseline, it's easier to deviate from it when necessary). Unless xper changes his mind on this, the answer is going to be no.

I am pretty sure that if you removed everything and rebooted the system with shutdown you'd still hit the same error. It's complaining that the state data from audit mode doesn't match the data currently even though it rebooted successfully. Only software or a user-initiated (click) action should be rebooting a machine in audit mode - anything that will interrupt msoobe's automated execution, aka, a reboot not initiated by software (TrustedInstaller) or a user-initiated action (explorer.exe) *will* interrupt MSOOBE - when the machine starts and audit continues, it will find it's MSOOBE state is "out of whack". If passing actual restart reasons to shutdown.exe do not fix it, you'll probably have to write an autoit script to emulate user clicks (or create an actual installation package that does indeed reboot the machine) to get around this one if this is Vista RTM. Windeploy.exe after the reboot launching audit.exe is actually where you failed reading information from the registry due to the unexpected reboot (this is where the data is stored and read every reboot) - windeploy.exe is the one "keeping track", and since the reboot was not user-initiated or software-initiated, your state data for /user no longer matches. A question, though - Is this in fact a Vista RTM image, by any chance, or is this an image with SP1 or newer integrated on it? There was a fix for a similar issue that was included in Vista SP1 or a GDR hotfix thereafter, I believe, that had to do with very similar behavior that I've come across in the past in working with Microsoft, for what it's worth. If this is an RTM Vista image, you might be able to create an SP2 integrated image and retry with that.

Something on this machine is leaking process and thread handles - the tags "Proc" and "Thre" (for process and thread object handles, respectively) are increasing in a steady climb over the time this was taken, so I'm going to go back to your .dmp file to see if I can pinpoint any handle or process object leaks there. It is worth noting that there are two processes, according to the spreadsheet this tool creates, that are *very* active during the time the leak is happening - is360srv.exe and SYSTEM. Given that IOBit probably has a kernel driver on top of it's service, this application is suspicious. The system is also showing a steady - small, but steady increase in MmSt, which is the tag you'd see if there was heavy activity on the disk or in memory, for example (moreso than just your everyday usage - it would ebb and flow, rather than show a steady increase with no real step down afterwards). I also see a fairly hefty leak in handles in is360srv.exe when looking at the process data spreadsheet, which also corresponds almost 100% with the Proc and Thre tag leak, making it my suspicious offender thus far. It will take some time to figure for sure from the .dmp (now that I know what I'm looking for), but this is the likely culprit going on my experience with this sort of behavior and what sort of thing causes these particular tags to leak (processes consuming and not releasing handles, probably to process and thread objects). Edit - yes, the dump shows is360.exe with *many* orphaned processes - there's a PEB, but there's no handle count and no threads. IOBit is the culprit here.

Well, that being the case, either it's a Win7 bug or a BIOS reporting issue (probably more likely the latter, but anything's possible - the battery issue previous was specific to HP models, so if you've found one that isn't HP I'm quite sure Microsoft will want to know and investigate). With that in mind, I would *strongly* suggest creating a Microsoft case in your region, and have them investigate this. You may have to escalate a few times to get an actual escalation engineer to work this, but that's probably what it's going to take. Microsoft Canada support is at (800) 668-7975. They'll likely have to work with you and the laptop OEM (if it's still under support) to figure it out.

Done.

You must not have a wealth of first-hand experience with the law .

You need to either create an account with a password, or enable the guest account (and give that guest account explicit access to the share and ntfs perms on the folder it points to). Otherwise, you can't connect from another machine, due to enhanced security in Vista and Windows 7.

Hmmm... I would strongly suggest burning and running a Ubuntu Live CD and see if you get the same problem there, as it charges and reads battery charging similar to how Windows 7 does it. If that also shows the error, you will need to contact Toshiba. The fact it says "not charging" means it's not exactly the same as the previous Windows 7 issue that brought about that hotfix. That would show "Consider replacing your battery" in the battery window - are you seeing that?

The reason qchain existed was to overcome the rename on reboot issue where multiple hotfixes could contain updates to the same file - qchain was used to make sure that only the latest file for each updated binary was placed during the reboot. Office does not have that problem, so I fail to see why you can't simply get the list of updates and apply them in sequence?

That is interesting - it would be worth getting a network monitor or wireshark trace of the client browser on Win7 connecting to your site to see what is happening at the network level.

I think I fail to understand your question?

OK, so that's not it. Do you know what BIOS version you have on that netbook?

Given what Wide Links does, I'm guessing that state is actually a Win32 status (not error, but status) message. Status is also an "error" code, which is basically a return from whatever check produces that state. 0x09 given how DFS works (and what fixes it) means it really is likely an incorrect or invalid SCB in the SMB request by DFS from the client.

What's the version of batmeter.dll on your system after installation of the update?

Yes, correct. But not documented for Windows 7. Your quote shows the date from January 2008 and belongs to Windows Server 2008 – long time before Windows 7. And I don't think that a "technical description" from January 2008 for "Windows Server 2008" is a legal enhancement for a licence agreement for Windows 7 from October 2009. Windows 7 uses the same volume activation technology as Vista and Windows 2008 - the way it handles suspected piracy is a bit different, but activation is the same. Documentation for VA 2.0 applies to Windows 7/2008 R2 as well as Vista/2008, because they're the same in this regard.

Actually, that is likely this error from winerror.h: ERROR_INVALID_BLOCK winerror.h # The storage control block address is invalid. This is due to non-optimal ordering in the DFS referral cache, usually caused by problems underneath the DFS layer. See KB905846 - the updated srv.sys is for fixes to sysvol and netlogon via DFS, so the error can exist in other places even with the fix (and I've seen it before, almost always with 3rd party NAS devices adding their own layer below the FS or network - Windows DFS *hates* this). Given that Wide Links (according to the OnStor documentation) allows for file symlinks to span multiple volumes or even devices, I have no doubt this will make DFS mad - someone's monkeying with file blocks underneath the FS, hence the storage block error you see . Also, the documentation for Wide Links makes it sound like this is a *replacement* for DFS (dfs server without a windows server - done right on the NAS). After reading how it works, it would seem you really can't use both at the same time - the documentation doesn't say you cannot, but given how it is documented to work by OnStor and knowing how DFS works, having them both enabled at the same time seems like a recipe for failure.

Where is it documented ? I don't find any link to a Microsoft internet site where it is documented. I only found one link to a Microsoft internet site where it is documented - for Vista.It's documented quite clearly in the activation documentation. But read this link exact: "This error may occur ... when you try to run the System Preparation Tool (Sysprep) ... and you use the /generalize option" And I think sysprep is only used by IT professionals. And does this mean you can run rearm more then 3 times ? If you read the article and the slmgr.vbs documentation, you'll note that slmgr -rearm is the same as sysprep /generalize. But this is not a free trial version for everyone. It's a trial version only for IT professionals. You can not download Enterprise version if you don't confirm that you are a IT professional.Correct. Microsoft provides the betas and RCs to everyone, but full versions require you to actually be an IT pro, mostly because the bulk of home users buy Windows from their OEM with a new machine, not from a store. If you want access to trial versions of an entire Windows OS, you must be either an IT professional (or say you are), an MSDN or Technet subscriber, or an OEM partner with access to the Action Pack.Given you're using slmgr.vbs, you are already far and away from a typical home user, and as such you are expected to read the documentation - especially documentation about activation and slmgr.vbs, as well as be an IT professional (or an aspiring one) to have gotten this deep into the OS' innards. There's an expectation from Microsoft that if you're tinkering with activation scripts, you're probably not a home user using an OEM copy of Windows, given that those are SLiC pre-activated.

There it is - nonpaged pool is almost 100% used: 0: kd> !vm *** Virtual Memory Usage *** Physical Memory: 851723 ( 3406892 Kb) Page File: \??\C:\pagefile.sys Current: 2095104 Kb Free Space: 1846332 Kb Minimum: 2095104 Kb Maximum: 4190208 Kb Available Pages: 593384 ( 2373536 Kb) ResAvail Pages: 754659 ( 3018636 Kb) Locked IO Pages: 43 ( 172 Kb) Free System PTEs: 125876 ( 503504 Kb) Free NP PTEs: 0 ( 0 Kb) Free Special NP: 0 ( 0 Kb) Modified Pages: 448 ( 1792 Kb) Modified PF Pages: 448 ( 1792 Kb) NonPagedPool Usage: 65534 ( 262136 Kb) NonPagedPool Max: 65536 ( 262144 Kb) ********** Excessive NonPaged Pool Usage ***** PagedPool 0 Usage: 9209 ( 36836 Kb) PagedPool 1 Usage: 1122 ( 4488 Kb) PagedPool 2 Usage: 1075 ( 4300 Kb) PagedPool 3 Usage: 1090 ( 4360 Kb) PagedPool 4 Usage: 1088 ( 4352 Kb) PagedPool Usage: 13584 ( 54336 Kb) PagedPool Maximum: 92160 ( 368640 Kb) ********** 434 pool allocations have failed ********** Session Commit: 1958 ( 7832 Kb) Shared Commit: 57142 ( 228568 Kb) Special Pool: 0 ( 0 Kb) Shared Process: 4826 ( 19304 Kb) PagedPool Commit: 13584 ( 54336 Kb) Driver Commit: 4313 ( 17252 Kb) Committed pages: 250189 ( 1000756 Kb) Commit limit: 1334017 ( 5336068 Kb) 0: kd> !poolused 1 unable to get PoolTrackTable - pool tagging is disabled, enable it to use this command Use gflags.exe and check the box that says "Enable pool tagging". It says pool tagging is disabled, so I would check that - but this is enabled by default in XP, so this error could be in fact because at the time of the dump the memory that contains this information is corrupt - assuming pool tagging is enabled, this is a likely source. However, we can use poolmon now that we're sure it's running out of nonpaged pool to "catch the thief" without resorting to crashing the box. Download poolmon3vbs.zip from here Extract this zip file to C:\Poolmon3 Double click C:\Poolmon3\_LogPool-as-a-service.cmd to start logging This should start a cmd prompt and start dumping log files to C:\Poolmon3. Let this run for about 24 hours, and then run C:\Poolmon3\_RemovePoolmon3service.cmd to stop the logging. Zip and upload the contents of C:\Poolmon3 so we can see what's happening.