Getting error from window service with Exception code: 0xc0000005

Question

We are getting error on server and our service is automatically stopped in the server. Randomly application is crash in approx 1 hour with below Error as -

Faulting application name: Chubb.Studio.Event.Processor.exe, version: 0.0.0.0, time stamp: 0x5c0ab1b7 Faulting module name: KERNELBASE.dll, version: 6.3.9600.19425, time stamp: 0x5d26b6e9 Exception code: 0xc0000005 Fault offset: 0x0000000000001556 Faulting process id: 0x115c Faulting application start time: 0x01d5a35fd202f96d Faulting application path: E:\WindowsService\DevInt\Chubb.Studio.EventProcessor\Chubb.Studio.Event.Processor.exe Faulting module path: C:\Windows\system32\KERNELBASE.dll Report Id: 762c15d4-0f5b-11ea-8120-005056a27597 Faulting package full name: Faulting package-relative application ID:

Our Code is look like as -

   protected override void OnStarted()
    {
        //IntializeEventsExecution();
        Task task = Task.Factory.StartNew(() => IntializeEventsExecution());

        base.OnStarted();

    }

    public void IntializeEventsExecution()
    {
        StartEvents();

    }

    public void StartEvents()
    {
        var eventList = GetEventTopics();
        Parallel.ForEach(eventList,
           new ParallelOptions { MaxDegreeOfParallelism = eventList.Count },
           (item, state, index) =>
           {
               StartProcessingEvent(eventList[(int)index]);
           });
    }

    /// <summary>
    /// 
    /// </summary>
    /// <param name="index"></param>
    public void StartProcessingEvent(EventTopic topic)
    {
        try
        {
            Task task = Task.Factory.StartNew(() => ExecuteProcessingEvent(topic));
            task.Wait();                
        }
        catch (Exception)
        {
        }
        finally
        {

            new _processingDelegate(StartProcessingEvent).Invoke(topic);

        }
    }

Answer 1

As Klaus says in his comment, a STATUS_ACCESS-VIOLATION exception is caused by a process reading or writing memory that it doesn't own. Given this is C#, the most likely reason is either an incorrect use of P/Invoke or using unsafe code.

The best approach to debugging something vague like this is to isolate the issue by removing P/Invoke calls one by one until the exception doesn't happen. It's hard to be more precise because the exception may be triggered a long way from the cause (memory or stack corruption).

This SO answer gives a good list of the likely causes of an access violation in managed code.

Access violations in managed apps typically happen for one of these reasons:

• You P/Invoke a native API passing in a handle to a managed object and the native API uses that handle. If you get a collection and compaction while the native API is running, the managed object may move and the pointer becomes invalid.
• You P/Invoke something with a buffer that is too small or smaller than the size you pass in and the API overruns a read or write
• A pointer (IntPtr, etc) you pass to a P/Invoke call is invalid (-1 or 0) and the native isn't checking it before use
• You P/Invoke a native call and the native code runs out of memory (usually virtual) and isn't checking for failed allocations and reads/writes to an invalid address
• You use a GCHandle that is not initialized or that somehow is pointing to an already finalized and collected object (so it's not pointing to an object, it's pointing to an address where an object used to be)
• Your app uses a handle to something that got invalidated by a sleep/wake. This is more esoteric but certainly happens. For example, if you're running an application off of a storage card, the entire app isn't loaded into RAM. Pieces in use are demand-paged in for execution. This is all well and good. Now if you power the device off, the drivers all shut down. When you power back up, many devices simply re-mount the storage devices. When your app needs to demand-page in more program, it's no longer where it was and it dies. Similar behavior can happen with databases on mounted stores. If you have an open handle to the database, after a sleep/wake cycle the connection handle may no longer be valid.