Limiting Surrogate Processes for Query Execution


I am using LINQPad for diagnostic purposes by referencing the assemblies and functionality used by our service hosts. It will ultimately open up ports for taking requests as well as connecting to our database. The reason for doing this is so I can have access to data such as preferences, permissions, etc. that are serialized in an encoded binary format in our database. It works well at replacing our testing console host, and I can prototype new code there as well.

The problem I am running into is that my LINQPad scripts initialize our system (connecting to the DB, opening up ports for listening, etc.) working fine the first time, but when running a second time, complains about something already listening on the same port. I then run the script a third time and it works correctly. It exhibits this same pattern consistently... every odd number try works, every even number try fails.

One thing I noticed when attaching the debugger, is that it seems there are potentially two surrogate processes that are hosting the query (LINQPad.UserrQuery.exe) and both of them are children of the main LINQPad.exe executable. In order for my hosted application to run correctly, I've had to make sure that the Execution properties of the query are set as follows:

I tend to suspect that LINQPad is probably alternating each of my runs between the two different surrogate processes which is why one works each time and still keeps the port open, while the other one ends up with the error because the other is listening on the ports. While I will probably modify my test harness to completely shut down the engine each time, I am wondering if there is any type of configuration setting which controls the number of child surrogate processes LINQPad creates for executing queries. I feel if I cut this down to one instead of two, I could at least avoid the alternating run problem.

Thank you!



  • LINQPad uses only one process per query, and doesn't kill that process unless something goes wrong with it. The additional process that you're seeing is what LINQPad creates in advance for when another process is required.

    What's happening, most likely, is that the query isn't releasing the port, and so running it again in the same process gives an error.

    Your query should go something like this:

    <listen on ports>
    <close ports>


    <listen on ports>
    Util.Cleanup += (sender, args) => <close ports>

    The Util.Cleanup event fires just before you re-run the query.

  • Thank you for the reply. The libraries I'm using that open the reports are our service engine. While I am calling a "Shutdown" method we've provided after my query executes, it is quite reasonable to think that maybe someone got lazy and just expected everything to close down when the process/service exits. Also, perhaps we're taking longer to properly shut down every time I keep re-running my query.

    It is kind of strange that the error occurs, then doesn't occur, then occurs, etc. with each and every run. At some point, the port is becoming available again, it's just strangely timed.

    Thank you for bringing the Cleanup event to my attention. I can certainly make use of that!

  • Just a quick follow-up... found the issue and fixed it. Thanks again!

Sign In or Register to comment.