Showing posts with label Windows 7. Show all posts
Showing posts with label Windows 7. Show all posts

Thursday, June 5, 2014

Computer on/off event viewer filter

Sometimes I want to track when I turned my computer on or off, including when it went to sleep or woke back up again.  To do that, I have created a custom view in Event Viewer on my Windows 8 system (should be the same for all systems from Vista and beyond, I assume). Go to Custom Views and click on "Filter current custom...". Switch to the XML tab and check the "Edit query manually" in the lower part. Now, paste the following in there:

<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">
    *[System
        [Provider
            [@Name='Microsoft-Windows-Kernel-Power'
            or @Name='Microsoft-Windows-Power-Troubleshooter'
            ]
            and TimeCreated    [timediff(@SystemTime) &lt;= 2592000000]
        ]
    ]
        or
    *[System
        [Provider
            [@Name='Microsoft-Windows-Kernel-General']
            and ( (EventID &gt;= 12 and EventID &lt;= 13) )
            and TimeCreated    [timediff(@SystemTime) &lt;= 2592000000]
        ]
    ]
   </Select>
  </Query>
</QueryList>

Basically, it is the equivalent of this, but only showing event 12 (switch off) and 13 (switch on) for the Kernel General source:




Please remember to "Save filter to custom view" if you want quick access to it later.

Sunday, March 4, 2012

SyncBack hang/freeze on Windows 7 - SMB version problem

Problem: SyncBack Free is a brilliant free tool for synchronizing two folders' contents fast and accurate. I had been using a Windows XP computer with two network cards standing as a bridge between two networks to sync folders between two computers residing on each side of the bridge. Old of age the XP computer were looking forward to its retirement as a young Win7 computer were set up to take over its place. The same SyncBack running the same SyncBack profile on the Win7 computer completely hung the SyncBack process within seconds after syncing was attempted. Only a reboot would kill the process - not even Task Manager managed to take it down.

Factors in the picture:
  • The two remote computers were running Win7  and Server 2008 R2.
  • Syncing between a local folder on the Win7 computer and one of the remote computers would work. Just not syncing between the two remote computers.
  • It made no difference whether Windows Shell (on the Copy/Delete tab) was used to sync or not.
  • Copying files between the remote computers from Windows explorer works just fine.
Problem reason: The reason proved to be SMB version. WinXP uses SMB 1.0, whileas Win7 uses SMB 2.0. For some reason, SyncBack does not manage to copy files between two remote computers as long as the computer is set up to use SMB 2.0.

Solution: Disable SMB v. 2.0, forcing the Win7 computer to revert to using SMB 1.0. This excellent article on Petri explains how - or here in short: From an administrative command line window run the following commands and then reboot to activate (Observe that "bowser" is actually correctly spelled - or rather, it is spelled the way that the computer understands):
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
If you need to revert to SMB 2.0, use the following commands:
sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto 
I have not put any effort into researching whether security is an issue with these settings or whether other functionality is negatively affected, for me it gave me what I needed, so I am happy.

Friday, December 9, 2011

Administrator cannot change, delete or take ownership of file

Problem: It is well known that if a file is locked in Windows, an administrator can take control of the file by taking ownership of it, give himself permissions to write/delete it and then perform pretty much anything he needs to do with the file. Sometimes, however, you just receive an error message when you try to take ownership, even though you are an administrator, and even though the command prompt or Windows Explorer you are working from has been started by right-click - "Run as administrator"

Solution: Open Computer Management and open shared folders - open files. If the file in question is being held by someone that has opened the file over a fileshare, you first have to terminate their connection to the file before you can manipulate it. Of course, you should first make sure you are not disturbing any work they are doing on the file.

Tuesday, October 4, 2011

Cannot connect to any computer except DC

Problem: The only network traffic (ping etc.) that could pass in a Win7/Server 2008 R2 domain was from each client computer to the domain controller. No client computer could contact each other. Even the domain controller could not initiate contact towards a client computer.

Reason: In the Server 2008 R2 active directory domain organizational unit (OU), a Group Policy Object (GPO) had been created to disable the local client's firewall and allow any network traffic (which was ok from a security point of view, since the network was completely disconnected from anything outside). When applied, the firewall was indeed not started, but somehow the idea backfired by blocking all but those client computer connections made to the DC.

Solution: The Firewall service was reenabled in the GPO:
Policies-Windows Settings-Security Settings-System Services-Windows Firewall-Startup type=Automatic
Instead the Firewall setting was set to off for the domain profile (which is the active profile for computers within a domain):
Policies-Windows Settings-Security Settings-Windows Firewall with Advanced Security-Domain Profile Settings-Firewall state = off

It seems absolutely illogical to me that switching off the firewall service would block most network traffic. Maybe some special case in my domain caused it - nevertheless, there was no doubt that my changes were the solution to my problem - even proven by the fact that reversing them would lead to reintroducing the problem.

Monday, September 5, 2011

ODBC 32 vs. 64 bit

Scenario: I needed to connect 32 bit software running on a 64 bit Windows 7 OS to an SQL server via ODBC. Using a User DSN, everything was fine - setting up a System DSN instead, the application could no longer find it or and connect to the database. I preferred setting up a System DSN, so that any user logged on to the computer would be able to run the software without further hassle in setting up the needed ODBC connection.
Cause: An ODBC System DSN in 32 and 64 bit versions are two separate matters, hence a 32-bit application will not see a 64 bit ODBC System DSN and vice versa. User DSNs are however visible on both sides. Confusing.
Gotcha: Both the 64 and 32 bit version of the ODBC tool's is named odbcad32.exe. Hence, the Win7 standard method of writing this in the search field at the bottom of the start menu would always give you the 64 bit version. You have to run %windir%\syswow64\odbcad32.exe (for instance via the run dialog, keyboard shortcut winkey-r) to start the 32 bit ODBC application.
Reference: Microsoft's Knowledge Base article 942976

Tuesday, August 16, 2011

Cannot logon to newly installed SQL Server

Problem: After a fresh install of SQL Server 2008 R2 on a Windows 7 computer, where Windows user group BUILTIN\Administrators were given administrative rights, I was not able to log on to the database from Microsoft SQL Server Management Studio while logged on to Windows as a user who was a member of the Administrators group and thus should have been granted access. The error received was: Login failed for user 'COMPUTERNAME\user'. (Microsoft SQL Server, Error: 18456).

Solution: Turn off User Account Control, or if you prefer to leave it on, make sure you start SQL Server Management Studio as an administrator (right-click the icon and select Run as administrator).

Tuesday, February 22, 2011

Win7: Restore .bat default behaviour

One of those small, very annying problems: I had managed to assign .bat files to open with my favourite cleartext editor (Notepad++ by the way), so that instead of running the bat file upon double-click, it opened in the editor. Now I wanted it reverted back to the original behavior.

I finally came up with a working solution: Just delete this registry key with all subkeys and life as you knew it before will be smiling to you again:

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.bat