Windows event log service holding executable file handle

Question

I have a service application that on startup and shutdown logs an event log record.

I rebuild the application frequently and also then the executable on the host machine. And here is the problem, after my service shutdown the Windows Eventlog service (not the event log viewer) is holding an open handle to the executable so I cant update it.

• I have the event log messages embedded in the executable, i could move it out but then I just move the update problem to another file.

• I've double checked and I have paired ::RegisterEventSource/::DeregisterEventSource correctly.

Anyone encountered this problem ?

Answer 1

I think it is probably the event log viewer. Close the viewer and you'll be fine.

Answer 2

I've also run into this issue, so just adding some of my experiences.

I have a Windows 2008 Service system (have not seen this on 2003 Server), and when I stop my service, and instance of svchost.exe loads the service executable (visible using vmmap.exe or Process Hacker) preventing it from being deleted/overwritten during uninstall/install. The instance of svchost.exe is running the DHCP Client (Dhcp), TCP/IP NetBIOS Helper (lmhosts), and Windows Event Log (EventLog) services.

In our case, we have created a registry entry to make our service executable an event source. (though I'm unsure exactly why we are doing this, or whether we should be doing this).

Empirically, if I remove that registry entry before stopping the service, the executable is not loaded by svchost.exe and all is fine. If the service has already been stopped and executable loaded by svchost.exe, restarting the Event Log service (or killing the process) also frees up the executable.

I'm guessing our service is not well-behaved (perhaps a side effect of being a 32-bit process on 64-bit OS?) or correctly installed, but haven't isolated the issue yet.

Update: It appears this issue is only happening on HP systems (and not Dell or IBM) which is curious. There are HP-specific management components installed, so perhaps one of them is altering the behavior somehow?

Answer 3

I've also run into this issue. In my case, nxlog service reading logs. Simply stop nxlog service before replace event source file.