Dealing with Selenium WebDriver Driver.Quit crashes (Where chromedriver.exe is left open)

We recently came across a problem with Selenium not quitting the webdriver and this would then lock a file that was needed on the build server to run the builds.

We were using Driver.Quit() but this sometimes failed and would leave chromedriver.exe running. I looked around and found this was a common issue that many people were having. We (I say we, as we came to the solution through paired programming), came up with the following, that would encapsulate the driver.quit inside a task and if this task takes longer than 10 seconds, then it will clean up any processes started by the current process, in the case of the issue on the build server, it would kill any process started by Nunit.

[AfterTestRun]
        public static void AfterTestRun()
        {
            var nativeDriverQuit = Task.Factory.StartNew(() => Driver.Quit());
            if (!nativeDriverQuit.Wait(TimeSpan.FromSeconds(10)))
            {
                CleanUpProcessByInheritance();
            }
       }

        private static void CleanUpProcessByInheritance()
        {
            var currentProcessPid = Process.GetCurrentProcess().Id;
            foreach (var process in Process.GetProcesses())
            {
                using (var mo = new ManagementObject("win32_process.handle='" + process.Id.ToString(CultureInfo.InvariantCulture) + "'"))
                {
                    mo.Get();
                    var parentPid = Convert.ToInt32(mo["ParentProcessId"]);

                    if (parentPid == currentProcessPid)
                    {
                        process.Kill();
                    }
                }
            }
        }

I've read quite a bit around this subject and it seems to be a common issue, that the driver.quit can leave the chromedriver.exe open, hence the need for the above method. Since implementing this fix we've not seen the locked file anymore on the build server, so hopefully it's solved. If not then I'll be sure to update this blog with (hopefully) a new workaround.