# out-of-process Published articles for out-of-process. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem DevFeed: [Why Rider and ReSharper Were Slow to Start, and How Microsoft Helped Fix the Problem]() Original publisher: [Read original article]() Author: Alexander Ulitin Published: 2026-09-09T16:45:27Z Content type: article Language: en Sources: [The JetBrains Blog]() Topics: [resharper](), [out-of-process](), [Latency](), [Microsoft](), [telemetry]() Tags: [defender](), [logs](), [microsoft](), [net-tools](), [oop](), [out-of-process](), [performance](), [resharper](), [resharper-oop](), [rider](), [telemetry]() ### AI overview The article investigates slow ReSharper startup after its out-of-process architecture was introduced. Profiling identified Microsoft Defender scanning as the source of substantial first-launch latency, and describes a repeatable investigation tool built with input from Microsoft. ### Source excerpt When we launched ReSharper's out-of-process (OOP) architecture, users reported slower startup times for IDEs using ReSharper on Windows. After profiling, the cause surprised us: Microsoft Defender was scanning our process for longer than we expected. This post is about what we found, what we learned working with Microsoft, and a tool we built that allows [...] ## Verifying an Agent's Work Against Reality, Not Its Own Report DevFeed: [Verifying an Agent's Work Against Reality, Not Its Own Report]() Original publisher: [Read original article]() Author: Philipp Lehmann (philipp.lehmann@gruppe.ai) Published: 2026-08-04T07:00:00Z Content type: tutorial Language: en Sources: [Philipp Lehmann]() Topics: [coding](), [out-of-process](), [ci](), [Processes]() Tags: [agent](), [agents](), [ci](), [ci-cd](), [out-of-process](), [repository](), [testing](), [tests](), [verification]() ### AI overview The article explains why a coding agent's transcript and successful wrapper exit are not reliable evidence that its task succeeded. It recommends defining observable completion criteria in advance, running verification in a separate process after the agent exits, checking the specific expected result, and reporting empty diffs separately from failing changes. ### Source excerpt git diff --quiet HEAD and a re-run test command in a separate CI job: verifying a coding agent's work from repository state instead of its own report. ## Python in Visual Studio Code - March 2026 Release DevFeed: [Python in Visual Studio Code - March 2026 Release]() Original publisher: [Read original article]() Author: Vedha Ranganathan Published: 2026-04-02T00:27:15Z Content type: release Language: en Sources: [Microsoft Python Engineering]() Topics: [Python](), [Visual Studio Code](), [Extension](), [Rust](), [out-of-process]() Tags: [2026](), [extensions](), [feature](), [improvements](), [out-of-process](), [parallel](), [performance](), [python](), [release](), [visual-studio-code]() ### AI overview Microsoft's March 2026 release of the Python and Jupyter extensions for Visual Studio Code adds optional search for Python symbols in installed packages and an experimental Rust-based parallel indexer for Pylance. The indexer runs out of process and is intended to improve performance, especially on large Python projects. ### Source excerpt The March 2026 release of the Python and Jupyter extensions for Visual Studio Code is now available. Keep on reading to learn more! The post Python in Visual Studio Code - March 2026 Release appeared first on Microsoft for Python Developers Blog. ## Handling crashes on Mac OS X: ordering of Mach exceptions versus POSIX signals DevFeed: [Handling crashes on Mac OS X: ordering of Mach exceptions versus POSIX signals]() Original publisher: [Read original article]() Author: Mark Seaborn (noreply@blogger.com) Published: 2013-08-07T20:25:00Z Content type: tutorial Language: en Sources: [Mark Seaborn]() Topics: [Operating system](), [Kernel](), [Processes](), [Exception](), [POSIX](), [out-of-process](), [Remote Procedure Call (RPC)]() Tags: [crash](), [dialog](), [exception](), [exception-handling](), [experimentation](), [handler](), [kernel](), [mac](), [mac-os](), [memory](), [ordering](), [os](), [out-of-process](), [posix](), [process](), [processes](), [rpc](), [signal]() ### AI overview This article explains how Mac OS X handles hardware exceptions through POSIX signals and Mach exceptions. It reports that Mach exception handlers receive priority, while the kernel uses a first-chance Mach handler, a POSIX signal handler, and a second-chance Mach handler when handling faults and crashes. ### Source excerpt Mac OS X is a curious operating system because its kernel is derived from two kernel codebases -- the Mach kernel and a BSD kernel -- that have been glued together. From these two ancestors, OS X inherits two different mechanisms for processes to handle hardware exceptions (a.k.a. faults): POSIX signals: In-process only. Registered per-process. The handler is always called on the thread that produced the fault. Mach exceptions: Allow both in-process and out-of-process handling. Can be registered per-thread and per-process. The handler is invoked via Mach RPC. On OS X, it's possible for a process to have both POSIX signal handlers and Mach exception handlers registered. It's not immediately obvious which of the two handlers will take priority and get invoked first, but experimentation shows that it's the Mach handler. If a process faults with a memory access error, the Mach exception handler for EXC_BAD_ACCESS gets invoked first, and if this handler returns KERN_FAILURE, the POSIX signal handler for SIGBUS will then be invoked. However, that's not the full story. OS X has a built-in Crash Reporter service which will create a crash dump if an application crashes and pop up a dialog box. Crash Reporter works via Mach exception handling and runs out-of-process. An application will normally have Crash Reporter's crash handler registered as one of its default Mach exception handlers. But what stops this handler from interfering with normal use of POSIX signals, if Mach exception handlers take priority over POSIX signals? The answer is that OS X's kernel has three steps for handling a hardware exception: First-chance Mach exception handler: The kernel tries to invoke the Mach exception handler registered for the type of fault that occurred, e.g. EXC_BAD_ACCESS. If there's no handler registered, it skips this step. If the handler returns KERN_SUCCESS, the kernel resumes the thread that faulted. POSIX signal handler: If the Mach exception handler was absent or returned KERN_