Develop Reference

Service Broker / External Application Activation and Visual Studio Debugging

I just got moved to a code-base that uses a lot of Service Broker functionality.
My EAService.config is setup as below
<ApplicationService name="NotificationTest" enabled="true">
<OnNotification>
<ServerName>MyServer\MyInstance</ServerName>
<DatabaseName>MyDatabase</DatabaseName>
<SchemaName>dbo</SchemaName>
<QueueName>MyQueueName</QueueName>
</OnNotification>
<LaunchInfo>
<ImagePath>C:\SomeFolder\SomeConsoleApp.exe</ImagePath>
<CmdLineArgs>myCommandLineArg1</CmdLineArgs>
<WorkDir>C:\SomeFolder\</WorkDir>
</LaunchInfo>
<Concurrency min="1" max="1" />
</ApplicationService>
My issue comes when I try to debug the above code.
Since the Service Broker External Activator (C:\Program Files\Service Broker\External Activator\Bin\ssbeas.exe) is instantiating the code....this is not something (to my best knowledge) that I can run in "Debug Mode" to wait for the call to come in and have a breakpoint set.
For example, with a WEBAPI project, I can do the traditional Start/Debug, and put a breakpoint on the ApiController/Method, and when a request comes in, it will break on the breakpoint, and I can pick up the debugging from there.
With Service Broker, it is instantiating some .exe....and the .exe may open and close so quickly, and I cannot "search and find" to attach a debugger to it.
I also thought, "Maybe I'll have Service Broker send messages to a WCF service", but that looks like it is not possible or very cumbersome to implement, based on what I read at this SOF post:
Service Broker and WCF interoperability
Is there anyway for me to do the above setup in EAService.config AND get the debugger to break as seen in the image below?
Or has anyone figured out a non hacky way to debug the C# code that is "activated" by Service Broker?

You have several options:
A. Modify the EAConfig to launch the program under debugger:
<ImagePath>C:\PathToDebugger\YourDebuggerOfChoice.exe</ImagePath>
<CmdLineArgs>C:\SomeFolder\SomeConsoleApp.exe myCommandLineArg1</CmdLineArgs>
B. Use GFlags image execution options to add a debugger to your app
C. Launch debugger from the app itself with Debugger.Launch()
D. Disable EA and run the application directly from VS (F5), for debugging purposes, then enable EA back.

So this is what I ended up with...as the most consistent method I could find.
static void Main(string[] args)
{
try
{
#if DEBUG
int index = Array.FindIndex(args, x => x.Equals("LAUNCHDEBUGGER", StringComparison.OrdinalIgnoreCase));
if (index > -1)
{
System.Diagnostics.Debugger.Launch();
}
#endif
<LaunchInfo>
<ImagePath>C:\SomeFolder\SomeConsoleApp.exe</ImagePath>
<CmdLineArgs>myCommandLineArg1 LAUNCHDEBUGGER</CmdLineArgs>
<WorkDir>C:\SomeFolder\</WorkDir>
</LaunchInfo>

Owin produces a lot of logging noise in the trace

I've got a small console application running TopShelf and using Serilog as the logging facility where I'd like to run OWIN inside. However as soon as I start the app builder, every log message gets duplicated via the trace listener and thus, printed out twice to the console.
// serilog sink configuration
new LoggerConfiguration()
.WriteTo.Trace()
...
.CreateLogger();
// topshelf
HostLogger.UseLogger(new SerilogLogWriterFactory.SerilogHostLoggerConfigurator());
I already found this answer here and included the following before I start the web host:
webHostOptions.Settings.Add(typeof (ITraceOutputFactory).FullName,
typeof (WebAppBuilder.NullTraceOutputFactory).AssemblyQualifiedName);
Trace.Listeners.Remove("HostingTraceListener");
The funny thing is: When I first started the application after inserting those lines, it worked (e.g. double messages were gone.). However after I cleaned my \bin directory, they started to appear again. What do?
Please check out this highly professional drawing I just made which should further explain the issue:
(zoom)

OWIN interferes with log4net

In my application, I've got the following logging strategy/appenders:
DebugAppender: If the root level is DEBUG, write every message that matches DEBUG to the default trace listener output
ConsoleAppender: If the application mode (global context property) is 'console', write every message above WARN to the console ouput
EventLogAppender: If the application mode (global context property) is 'service', write every message above ERRROR to the console output
RollingFileAppender: Write every message above INFO to a rolling flat file
This works very well throughout the whole application, until the very first line I'm starting the OWIN web host using the IAppBuilder interface. As soon as I invoke WebApp.Start, I noticed the following behavior:
Debug messages (ILogger.Debug) are getting written to the console output
Debug messages (ILogger.Debug) are getting written twice to the VS debug output
Upon further investigation, I figured out that OWIN silently attached an instance of System.Diagnostics.DefaultTraceListener and System.Diagnostics.TextWriterTraceListener to the default trace/debug ouput, which may be the root of the problem. However, declaring the DefaultTraceListener in app.config explicitly didn't help.
Is there any way I can configure OWIN to be less... sneaky?

You can remove the listener in startup code, eg:
Trace.Listeners.Remove("HostingTraceListener");
(Name from source code)

Windows Service not working when installed, works fine in Debug mode; crashes on Moving/deleting files

I created a windows service which watches a directory. When a file is dumped into it, it takes the data and puts it into a database. Then this file is moved to another directory and deleted. It works fine in debug mode. But when i install it on my computer it stops after throwing the data into the database and the file in question is neither moved or deleted. I suspect a permission issue is involved. I tried to create a event log:
public Service1()
{
InitializeComponent();
if (!System.Diagnostics.EventLog.SourceExists("MySource"))
{
System.Diagnostics.EventLog.CreateEventSource(
"MySource", "MyNewLog");
}
eventLog1.Source = "MySource";
eventLog1.Log = "MyNewLog";
}
So i have three questions.
(1) What could be causing my service to work as described in debug but fail when installed on my computer.(2) I have initiated a event log as shown above. But do i need to add other code to record the event of my service stopping. I presume this would be done in a 'override onShutdown' method.(3) Finally when my service stops, i want to look at the event log. But i do not know how to do this, is in administrative tools? stored as a file on some directory?
Here is edit to this post in lieu of the grateful advice given below.
try
{
File.Move(e.FullPath, finalString);
File.Delete(e.FullPath);
}
catch(Exception q)
{
EventLog.WriteEntry("MySource", q.ToString(), EventLogEntryType.Error);
using (StreamWriter w = new StreamWriter(ConfigurationManager.AppSettings["fmd"], true))
{
w.Write(DateTime.Now.ToString("dd-MM-yyyy_hh-mm-ss"));
w.Write(q.ToString());
}
}
As per suggestion i put a try-catch around the file move and delete plus i added a OnShutdown method:
protected override void OnShutdown()
{
using (StreamWriter w = new StreamWriter(ConfigurationManager.AppSettings["ond"], true))
{
w.Write("stop OnShutdown");
}
//EventLog.WriteEntry("MySource", message, EventLogEntryType.Error);
}
I do not know how to pass any system error message to the shutdown method, so any advice appreciated. When i installed my modified code as a service, it again stopped before moving or deleting the files. Neither of my two logs accessed by a stream recorded anything. Plus the event viewer showed nothing either?

You can write as following,
if (!EventLog.SourceExists("MySource"))
EventLog.CreateEventSource("MySource", "Application");
EventLog.WriteEntry("MySource", message, EventLogEntryType.Error);
to view the event log messages, Goto Administrator Tools -> Event Viewer and look for the source you have created. or Just simply type eventvwr in run window.
When Services installed, it works under SYSTEM User account where service might not have access to some resources. Please put logs and see where exactly the issue is.
If you service installed in your development machine, use attach to process option under DEBUG Menu in Visual Studio to find out.

What could be causing my service to work as described in debug but fail when installed on my computer?
Permissions. The service is likely running under LocalSystem or Network Service if you didn't provide a different identity.
I have initiated a event log as shown above. But do i need to add other code to record the event of my service stopping. I presume this would be done in a 'override onShutdown' method?
Yes, you're assumption is correct.
Finally when my service stops, i want to look at the event log. But i do not know how to do this, is in administrative tools?
Just hit Windows Key+R to get the Run dialog and type eventvwr.

Well i found the reason for all the commotion. I eventually found some logs in the event viewer. They were listed in Administrative events in custom logs. There were three error logs: .Net runtime; Application error & Service Control Manager. In '.Net Runtime' the stack showed a unhandled exception for system.windows.forms. I stupidly included a pop up box in my release version. But even when i commented this away; i got a error. So i went back and found other message boxes, primarily in try catch statements. Removed these and solved the issue.

Visual Studio 2012 debugging of remote process not working as expected

I am struggling with a rather difficult debugging challenge and hoping that someone might have some clues how to make this work.
Here's the scenario:
I have a C# Windows service that runs under a user account with admin privileges and launches a separate executable process under a user account that has standard user privileges. The two processes are designed to communicate using WCF.
Unfortunately, when the child process is launched, it crashes immediately, with nothing in the event log that suggests what happened. The parent process continues running without exceptions.
For information: these two applications work reliably together in a configuration whereby the parent process is a desktop application. I have also had success with the parent as a Windows service, but only when both processes run under the same user account with admin privileges.
I now need to reconfigure their relationship to restrict the privileges of the child process, but this is when the crash occurs.
In order to prove that what I am trying to do is feasible, I have created two stub applications and launched them successfully in the desired configuration. So, I can deduce that my real child app contains something that is incompatible with this configuration and which causes a crash even before the code starts executing. Unfortunately, since the child process is a based on some rather complex legacy code, it is not easy to isolate its elements until I eliminate the problem, so I really need a reliable means of stepping through it.
If I modify the code of the child process to launch debugging immediately on startup, it invites me to attach a debugger, but fails to complete the attachment, with a message that indicates that The Just-in-time debugger does not have permission to debug the process.
I have also seen this question and attempted to implement this proposed solution (which looks really promising) but it fails to work in my scenario. Instead of launching debugging prior to launching the application it appears to do nothing - niether the debugger nor the application are launched and the debugging invite dialog is not displayed. However, I have verified that this technique works in my environment (by using it to launch Notepad.exe) so there is clearly something about my application or the way that I am launching it that is causing the problem.
I am happy to experiment and to share more details about my test results, if anyone has any suggestions.
Many thanks for your ideas,
Tim

The fact that the debugger never starts for the child means the error should be occuring in the PARENT server process. If you properly set the Image File Execution Options (which is easiest to do using GFlags program using the free Windows Debugging Tools from Microsoft), then that means you never start creating the child. The simplest way to test this is by adding an Assert to your code, right before the create child process call, build your parent service in debug mode, install/register it as a service, and start it up. When the Assert pops up, attach to the process, and start debugging from there. You should then see the create process error occuring in the parent.
If you want to interactively debug both the parent service and the child process, you can do this using WinDbg and GFlags, but it will be complicated.
You will need WinDbg and GFlags. These tools are included free from Microsoft as part of the Debugging Tools for Windows. You can find that free software package here:
http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Use GFlag to set the execution option for your PARENT SERVICE with the following debugger options:
"C:\Program Files (x86)\Windows Kits\8.0\Debuggers\x86\WinDbg.exe" -server tcp:port=5000:9000 -o -g
When Windows starts your parent service, it will do so under WinDbg. Because of the -o option, WinDbg will also manage the launched child process, allowing you to interactively DEBUG the child from start up. Because of the -g option, WinDbg will start the ParentService up and let it run, rather than stop it at load up as is normal debugging behavior. This will prevent Windows SCM from shutting it down and starting a new instance.
Because you are running a service, it will not have access to the desktop, so neither will its host WinDbg. You will have to attach ANOTHER debugger to the running instance of the WinDbg running your ParentService. You can do this using another WinDbg instance. To do that, start a second instance of WinDbg, and connect remotely by using the menu item "File|Connect To Remote Session...". At the dialog, put in:
tcp:Port=5000:9000,Server=[machinename]
Once you are connected, you will be able to work with your ParentService.exe, and when it creates the ChildProcess, the executing context will swap to it, and you will be able to debug it as well.
I've used this technique to debug a child process created by a windows service before. It isn't as easy as just debugging something in Visual Studio's built in debugger in its IDE, but it does work.
WinDbg has extensive documentation available for it, both from Microsoft and from other sources online. The URL I provided above includes links to WinDbg documentation.
I recommend using GFlags because it will make all the necessary edits to your Registry for running executables under a debugger of your choice. It also does much more, and is worth the time to learn about.
It is possible to set up breakpoints and set all sorts of options when WinDbg starts. I replace the -g option with the command line option:
-c "$$<c:\MyDebugCommands.txt"
This instructs WinDbg to run a command, and the command is to run a WinDbg script named "MyDebugCommands.txt". I populate MyDebugCommands.txt file with all the set up changes I need (such as load symbol options), as well as setting the breakpoints I am interested in, with the final command in the file being -g
As I said, it isn't as easy as just using the VS IDE and its built in debugger, but it will let you interactively debug your parent service and its launched child process.

According to my tests based on your scenario above (parent process is service with admin rights, child is console without admin rights), I see the same debugging error as you when I artificially force the child process to throw a permission exception as soon as it starts. The error message in this instance might be misleading, as it's not clear that this is actually a debugger permission problem
It would be useful to know what type of application your child process is, because that will affect the debugging options that you have.
The first way I've tried to debug this is to intercept all unhandled exceptions in my child process (a console app). You can do this by adding the following code in the start-up procedure of your child app:
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(App_UnhandledException);
Then I added code to my App_UnhandledException procedure to log the exception. This worked for me, and I could see the reason for the permission error. The only caveat is that this won't intercept an exception where your app won't even load because of the permission problem. But this approach should at least reduce your search space in understanding the permission problem.
If the exceptioon is generated before your exception handler is reached, another possiblity is to use the assembly binding log viewer. This is a very useful tool.
FWIW you can step through your service code (but unfortunately not into your child process) by starting your service within Visual Studio. The code shown below in the switch case called DEBUG will let you start/debug your service within VS.
// This is the entry point
static void Main(string[] args)
{
// If parameter passed, act on it
if ( args.Length > 0 )
{
switch (args[0] )
{
// Debug the service as a normal app from within Visual Studio
case DEBUG:
MyService DebugService = new MyService();
DebugService.OnStart(null);
break;
// Install the service programatically
case INSTALL:
ManagedInstallerClass.InstallHelper(new string[] _
{ Assembly.GetExecutingAssembly().Location });
break;
// Un-install the service programatically
case UNINSTALL:
ManagedInstallerClass.InstallHelper(new string[] +
{ UNINSTALL, Assembly.GetExecutingAssembly().Location });
break;
// We don't understand this parameter!
default:
message = string.Concat(DEBUG, " to run service manually.", Environment.NewLine);
message += string.Concat(INSTALL, " to install service.", Environment.NewLine);
message += string.Concat(UNINSTALL, " to un-install service.", Environment.NewLine);
message += string.Concat("Do not understand the command-line parameter ", args[0]);
throw new System.NotImplementedException(message);
}
}
// If no parameter passed, just start the service normally
else
{
ServiceBase[] ServicesToRun;
ServicesToRun = new ServiceBase[] { new MyService() };
ServiceBase.Run(ServicesToRun);
}
}

Have you tried running Visual Studio as Administrator and calling the Process.EnterDebugMode() method?

If I modify the code of the child process to launch debugging immediately on startup, it invites me to attach a debugger, but fails to complete the attachment, with a message that indicates that The Just-in-time debugger does not have permission to debug the process
Run secpol.msc as administrator and under 'Local Policies | User Rights Management' select 'Debug Programs'. Then add the 'Users' group to that. See if that fixes the permissions issue.
HTH