Stopping SqlDependency gracefully

I have an application that utilizes SqlDependency objects to track changes on certain tables of data in an underlying database.

For the most part they work well, however, I noticed when I try to kill the dependency using the static Stop() method of the class, I get the following exception:

A severe error occurred on the current command. The results, if any, should be discarded. Operation cancelled by user.

That's about all the information the runtime provides. On the databases end the log is littered with a repeating type of error:

The query notification dialog on conversation handle '{59CC17D7-DB61-E311-BF57-00151796FDC4}.' closed due to the following error: 8490 Cannot find the remote service 'SqlQueryNotificationService-058a0d35-359a-478e-b227-427d7dabc62c' because it does not exist.

Presumably, this is a consequence of the application not terminating the dependency correctly, and leaves the notification service with zombie entries. It doesn't appear to be causing any adverse effects, but for every client that isn't terminating correctly the log gets flooded with these notification errors... Not to mention it's just bad practice.

Why is this happening? I would think that by calling Stop(), all existing handles to change events would be released. If this is not the case, how would you gracefully release all open handles? I can't explicitly release them because the queries to the data are dynamically driven by the application; I don't know at any given time what the user decided to pull. Only what they queried is bound by a dependency.

No, there isn't any way to properly shutdown SqlDependency. The design choices of using a just-in-time deployed queue and service for each application instance subscribing to query notifications makes it easy to use, but has some negative consequences, and you see them when these error messages pop in your errorlog. Most times these error messages can be safely ignored, but they may have some negative consequences.

For the brave ones one can take control of its destiny and use the more basic SqlNotification, see Using SqlNotificationRequest to Subscribe to Query Notifications. This class does not attempt to deploy a service and queue on your behalf, it expects you to do the 'dirty work'. The upside is that you have control and can avoid the problems that plague SqlDependency Start()/Stop() (permissions for start, inappropriate shutdown order etc).