adamt

You can still find Office 2003 SP3 at the MS update catalog site. You might also want to make sure that Windows 10 has the latest available servicing stack update.

Usually, with an expired password, you would still be able to login, but you'd be prompted to change it.

Are you sure the password is still blank? Could somebody have changed it? Once you get back in again, check your security log for event ID 4738.

On the HP ProLiant SmartArray devices I have used, the cache is disabled when the battery loses charge or registers a fault. This is done to prevent the loss of data in the event of a power outage. It's easier for HP to support a disk performance issue that they can just tell you to replace the battery for, than it is to recover a corrupt database. When the battery fails, or has no charge, event ID 1206 from Storage Agents will be logged to tell you about the battery failure. Event ID 1204 will also be logged to tell you that the cache accelerator module has been disabled.

It's set to "Ignore", and the "Make this action the system default" is checked.

Dear all, I am trying to run silent/unattended installations of NetBackup client 7.1 - which includes the driver wimfltr.sys. Unfortunately, that driver's certificate expired in 2008. According to that article, this can be ignored should not prevent installation - but unfortunately, it does. At least on some Windows 2003 SP2 x86 servers. They all have the group policy item "Devices: Unsigned driver installation behavior" set to "Silently succeed", and all have the "Driver Signing\Policy" registry key set to 00. But some are logging the following in the setupapi.log file: [2013/06/20 08:43:34 5780.1] #-198 Command line processed: "C:\WINDOWS\system32\rundll32.exe" setupapi,InstallHinfSection DefaultInstall 132 C:\WINDOWS\system32\drivers\Wimfltr.inf #-011 Installing section [DefaultInstall] from "C:\WINDOWS\system32\drivers\Wimfltr.inf". #W367 An unsigned, incorrectly signed, or Authenticode signed file "c:\windows\system32\drivers\wimfltr.inf" for will be installed (Policy=Warn, user said ok). Error 1168: Element not found. #-024 Copying file "C:\WINDOWS\system32\drivers\WimFltr.sys" to "C:\WINDOWS\system32\DRIVERS\WimFltr.sys". #W363 An unsigned, incorrectly signed, or Authenticode signed file "C:\WINDOWS\system32\drivers\WimFltr.sys" will be installed (Policy=Warn). Error 0xe000022f: The third-party INF does not contain digital signature information. When this happens, the installation halts, waiting for somebody to click OK. As this is an unattended installation, nobody will see this prompt unless they logon to the console (session 0). I can't find which setting it might be that is causing some of these servers to choke on the wimfltr.sys file, whereas others succeed. It happens on machines upgrading from the same previous NetBackup client versions, and with the same version of the setupapi.dll file. Apart from the resultant set of policy, local computer policy and the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Driver Signing\Policy registry key, where else should I be looking to find out why some servers are logging "Policy=Warn" in the logs? Many thanks, Adam.

Just wondering - in your DHCP scopes, are you instructing the clients to use the old Win2k3 server as their primary DNS or WINS server? Can you try to validate the IP configuration of one of the affected machines? Test NSLOOKUP against all DNS servers and compare times?

There are many reasons why this might be. Firstly, as allen2 has told you, the space may be used up by pagefiles, shadow copies, hiberfil, etc - files which are usually hidden from the shell unless you configure it otherwise. Then, bear in mind you there's things like reparse points (junctions), compressed files, etc - see: Computing the size of a directory is more than just adding file sizes on Raymond Chen's blog, and the similar Windows Confidential article he wrote for an overview.

Hi, I've recently had an issue in which a customer application had bloated the HKLM\Software bit of the registry to 2 GB. It was 32-bit COM application running under a 32-bit dllhost.exe process on x64 Windows Server 2003, and was filling up HKLM\Software\Wow6432Node\Microsoft\EventSystem. I was able to use dureg.exe from the Windows 2000 reskit to find which bit of the registry was taking up all the space. However - I noticed that dureg.exe is (being from the Win2000 days) an x86 application, and so although it reported that it was reading HKLM\Software\Microsoft\EventSystem, it was actually being redirected to Wow6432Node. That didn't really matter in this instance, as it just so happened that the bloated key was under Wow6432Node. But what happens if you have a similar issue with an x64 application, filling up the registry in an area which a 32-bit application can't read? I can't find a native 64-bit version of dureg. I was looking at writing something to do the same sort of job, but the RegistryKey class doesn't seem to expose a 'Size' property. Any suggestions of how the size of a registry key (including all sub-keys and values) can be enumerated in C, C#, C++ - or better yet, any suggestions for alternative tools which would do the job? Thanks, Adam.

Do you have permissions to edit the \boot.ini file? And if you make changes to it using msconfig - does your boot.ini file get updated with them?

Dear all, I have one server environment which seems to be generating quite a lot of these events, mostly from Win2k3 SP2 machines: Event Type: Warning Event Source: Srv Event Category: None Event ID: 2012 Date: 27/08/2011 Time: 07:05:25 User: N/A Computer: WIN2K3WEB Description: While transmitting or receiving data, the server encountered a network error. Occassional errors are expected, but large amounts of these indicate a possible error in your network configuration. The error status code is contained within the returned data (formatted as Words) and may point you towards the problem. Data: 0000: 00040000 00540001 00000000 800007dc 0010: 00000000 c0000184 00000000 00000000 0020: 00000000 00000000 0000097b I'm 99% sure this is down to some Riverbed CIFS devices, which are making it appear that a connection is still open for business when it has in fact already been closed at the remote end. Anyhow - I know that the c0000184 signified STATUS_INVALID_DEVICE_STATE, and I've worked out that 800007dc actually just means 'this is event ID 2012'. What I'm wondering about is what the 00040000 00540001, and the 0000097b mean. Sometimes, instead of 0000097b, it is 0000097a. This doesn't appear to be a Win32 error code, and it looks nothing like an HRESULT or NTSTATUS value. Any pointers on what these values mean? Thanks, Adam.

You could download Process Monitor from Sysinternals, and run that, looking for what is accessing that key. Start process monitor with the /noconnect switch (c:\path\to\procmon.exe /noconnect) - which will stop it from instantly logging every single bit of activity from the second it loads. Add a filter: If path excludes "CodeASU1" then Exclude. Also, use the 'drop filtered events' option - to stop it from filling up your pagefile. Now tell it to start capturing events, and from there on, it's a waiting game to see which processes are touching that key.

Obviously, it's a bit late now, but I would have suggested looking for the following registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\ NoDrives (DWORD) = 1. If it's there (and not set to 0), Explorer will hide some/all drives from you. Full explanation of the key is at: http://technet.microsoft.com/en-us/library/cc938267.aspx

I sometimes find that I need to kill my rdpclip.exe process, then run it again to resolve RDP clipboard issues. There's one rdpclip per logged on user, so be sure you kill the right one. I have seen one case of a TS box which wasn't even trying to run rdpclip.exe. The problem was with the registry keys: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd\ StartupPrograms = (String). HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AddIns\Clip Redirector\ Name = (String). On _most_ Terminal Servers, these string values are equal to “rdpclip”. The problematic one had them set to "fxrdpclp", which is some kind of Win2000 Resource Kit utility, and wasn't actually present on the server. You might be interested in this article, which explains a bit more about clipboard chaining, and why it's better in Vista/7/2008: http://blogs.msdn.com/b/rds/archive/2006/11/16/why-does-my-shared-clipboard-not-work-part-1.aspx

Only Windows (Win2000 or later) machines understand authorisation. Other OSes won't check for auth. before handing out IP addresses. If the DHCP server did not live on the same subnet as the clients, it would need to have had a relay or ip helper pointing traffic towards it - else it would only have been able to offer/renew IP addresses to machines on the same local subnet. I'm not sure how this could have corrupted your DHCP database, though. In any case - we have a script which runs weekly on all DHCP servers, saving their configuration and the details of all IP reservations. Should anything go haywire with the DHCP service, we would be able to quickly restore it. It also allows us to periodically review the IP reservations to see which might not be needed anymore.

Assuming this is a BHO (Browser Helper Object), the configuration should be stored at: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects If it's a Browser Extension rather than a Helper Object, it will be at: HKLM\Software\Microsoft\Internet Explorer\Extensions - both are per machine, rather than per user, although there may also be relevant data stored under the HKCU hive, which is specific to the user, not the computer (such as whether to display a toolbar, and what dimensions to make it). It is also possible to find extensions under HKCU\Software\Microsoft\Internet Explorer\Extensions, which would be per user, although this seems to be rare - and the fact that your add-in works fine for multiple users suggests that this is not the case here. It could be that the specific BHO/Extension you are using cannot be accessed by non-administrators. Perhaps some files are written somewhere that only admins have access to (such as the user profile of another administrator). For example, the Adobe Acrobat BHO installs a DLL at C:\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEHelperShim.dll. If non-admins didn't have permission to read this file/directory, they would be unable to load the add-on. It might be time to dig out procmon.exe, and monitor what iexplore.exe is doing when you try to use/view the add-on as both admin and non-admin.

Interesting idea, and one I'd like to try. Would you need a serial/kernel debug session, or should I just be able to attach to dfsutil and see what I'm looking for? Thanks, Adam.

Thanks for the suggestion. DComLaunch and RpcSs are actually already in their own svchost.exe processes. A quick straw poll around some Win2003 machines suggests this is the default for that OS (although I notice that on my XP laptop, DComLaunch shares a process with Terminal Services).

Replying to my own post, in case anyone else is interested - I'm going to setup adplus to monitor the specific instances of svchost.exe which host DComLaunch and RPCss. If I find anything useful, I'll post the details back here.

It can't be coming from winerror.h, because healthy cache entries appear with status 0x19, and "The drive cannot locate a specific area or track on the disk." does not make any sense in this context. Also, surely an error regarding tracks on disks would need to come from something like ntfs.sys, rather than mup.sys or rdr.sys?

Well... if it is a status code, or an error code - it must be defined somewhere, else all error messages would just generate a random number. Since it isn't in winerror.h or ntstatus.h, I was wondering where it is defined.

Interesting... where would that be defined if not in winerror.h or ntstatus.h?

I didn't consider it to be a win32 error code because other healthy cache entries appear with status 0x19, and "The drive cannot locate a specific area or track on the disk." does not make any sense in this context. Once the DFS element had been discovered, we disabled the WideLinks setting and all was resolved. Curiously, LSI/OnStor did not seem to think that WideLinks could possibly be the cause of such an issue.

Just to reply to my own thread... I found that running dfsutil.exe /pktflush would alleviate the issue temporarily (which is easier to do than reboot the machine). For this specific issue, running dfsutil.exe /pktinfo will show you an entry with "State:0x09" for each file you are unable to access: Entry: \uk6nas03\nas-l4\mb2c\stage\ZZ_915939_IN\ruby\config.xml ShortEntry: \uk6nas03\nas-l4\mb2c\stage\ZZ_915939_IN\ruby\config.xml Expires in 0 seconds UseCount: 0 Type:0x81 ( REFERRAL_SVC DFS ) 0:[\uk6nas03\nas-l4\mb2c\stage\ZZ_915939_IN\ruby\config.xml] State:0x09 ( ) The troublesome NAS devices were OnStor/LSI BobCat devices, and they had 'widelinks' enabled. Once this was disabled (we weren't using it), the issue never returned. Still seems bizarre, and I've been unable to find out what state 0x09 maps to. At least everything's working now, though.

Dear knowledgeable MSFN-dwellers, I have a Win2k3 R2 x64 server which has on various occasions, suffered a crash of the DCOMLaucnch or RPCss services, causing the machine to reboot. It leaves an entry in the system log like this: Event Type: Information Event Source: USER32 Event Category: None Event ID: 1074 Date: 21/11/2010 Time: 00:32:28 User: NT AUTHORITY\SYSTEM Computer: LON-SQL105a Description: The process winlogon.exe has initiated the restart of computer LON-SQL105a on behalf of user NT AUTHORITY\SYSTEM for the following reason: No title for this reason could be found Reason Code: 0x30006 Shutdown Type: restart Comment: Windows must now restart because the DCOM Server Process Launcher service terminated unexpectedly Unfortunately, there's no drwatson dump file generated (although Dr Watson is configured as the default debugger). How can I capture the details of the crash for analysis? There's no sign of malware on this server, and I'm a little puzzled as to what could cause these crashes. Thanks in advance, Adam.