Automating DLL Debugging "attach to process" in Visual Studio? - c++

I'm writing an SNMP extension agent DLL for Windows.
Is there a way to automatically attach the DLL to the SNMP service each time I want to test/debug?
This is a very tedious and time consuming process, as I currently have to stop the SNMP service, compile, restart the service and then attach the process. I'm trying to automate it more.

This may be what you want to have a look at.
Visual Studio debugger offers some command line option to attach to running process. You can probably write a Python script to enumerate running processes and attach the debugger to the service. I think you need admin priviledge to do that.
.Net has a convinient Debugger.Launch(), but I can't find an equivalent for the native.

Related

Running a Visual C++ 6 Console Application as a Windows Service

Is it possible for a Win32 Console Application to be used as a Windows service?
Normally this wouldn't be an issue using C#, .NET, and Visual Studio 2010 or higher, but this is a legacy application that was written in C++ using the Visual C++ 6 environment.
Mainly for the ability to restart itself after a crash.
Is it possible for a Win32 Console Application to be used as a Windows service?
Yes. In fact, many services are written as console apps. Even MSDN examples are.
The app's main() simply needs to call StartServiceCtrlDispatcher() to establish a link to the Service Control Manager:
Writing a Service Program's main Function
Mainly for the ability to restart itself after a crash.
The correct way to handle that is to just let it crash. Use ChangeServiceConfig2() to configure the service's SERVICE_CONFIG_FAILURE_ACTIONS info. One of the available actions is SC_ACTION_RESTART.

How to Remotely Debug a System Startup Component?

Because of the possibility of full system failure, I am using VM's as the environment for debugging a system startup component like "userinit", which executes before the desktop appears. How do I configure the VM's remote debugger and system so I can debug from the first line of code?
Look here:
Setting Up Kernel-Mode Debugging Manually

Application hangs when debugged with Application Verifier

I added my C++ application to Application Verifier. I am able to run it by directly executing the exe. But if I run it from VS 2013 or WinDbg, it just hangs with 0 CPU usage.
Even if I directly execute the exe, at a certain point it uses all my memory (10GB), and I have to restart the computer. So now I do not have a way to use Application Verifier to debug it.
There is only one line log created when my application starts. I do not see any other logs in Application Verifier.
Does anyone know what is wrong with my case?
If I disable the TLS option in Application Verifier, it will work in a debugger.

Command line application running as a windows service. Getting error 1053

I have created a c++ command line application. This application sends a revives messages from other computers and logs the results to a file. A simple application. One of the first things the app does is write to the log file the start up time.
Now that I have gotten the application to a good place, I want to install it as a service that runs on my computer (win 7).
I am using the NSIS, Simple_Service_Plugin to install the application and register the service in windows. I can see the service in windows service manager.
When I attempt to start the service, I get the following error message. The log file does not get created.
Windows could not start __THE_APP__ service on Local Computer.
Error 1053: The service did not respond to the start or control request in a timely fashion.
When I start the app from explore it starts without any problems and the log file is updated correctly.
When I search this error message on-line I find lots of help for C# and .Net applications and nothing for c++ apps.
My question is:
How do I start a C++ application (not dot.net) as a service?
A service isn't a regular appliction. It's a program that uses specific system classes and implements certain features that enable the OS to communicate with it.
See here (and the surrounding pages) for more details.

Windows event log service holding executable file handle

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 ?
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?
I've also run into this issue. In my case, nxlog service reading logs. Simply stop nxlog service before replace event source file.
I think it is probably the event log viewer. Close the viewer and you'll be fine.