[Skimmertalk] Solution found for SkimSrv Error Access Violation (tried to write to 0x00000014)

[Bob Wilson, N6TV]

I *think* I finally found a cure for this issue, as my Skimmers finally
stayed up all night, for the first time in a week.  They had been crashing
every few hours, ever since Windows 10 was "upgraded" to KB4343909 (OS
Build 17134.228)
<https://support.microsoft.com/en-us/help/4343909/windows-10-update-kb4343909>.
I also tried a Lenovo BIOS update, and many other things, but nothing cured
it until ...

Solution:

Settings -> System -> Power & Sleep
Click *Additional Power Settings*
(or use Control Panel -> Hardware and Sound -> Power Options)

*Balanced (recommended)* is selected by default

Select *High Performance* then click *Change plan setting*

Click *Change advanced power settings*

Under *Hard disk*, change *Turn off Hard Disk after -> Setting (minutes):  *
to *0*  (or "Never").  The default is 15 minutes.  No other changes
required.

Click *Apply* and *Save Changes*.

That's it.  No more crashes.

Background:

My Windows 10 desktop has two disk drives.  Drive C:, where the OS and
Skimmer is installed, is a 512 MB solid-state drive (SSD).  Drive D:, which
mostly contains data and installation programs (but no log files), is a 1
TB spinning hard disk.  Only drive C: directories are in the Windows PATH.

Before, after 15 minutes of inactivity, drive D: would spin down (I could
hear it).  I could also hear it spin up whenever I moved the mouse to wake
up the system, and noticed that SkimServ would immediately crash every time
drive D: spun up.  I assume anti-virus scans by Windows Defender or
MalwareBytes or other system activities would periodically do similar
things to spin up drive D: in the middle of the night, which would also
cause SkimServ to crash.

By keeping it spinning, whatever I/O interrupt delays caused SkimSrv to
fail seem to be avoided.  Maybe someone at Microsoft or Lenovo will
eventually figure out what they broke, and I'll be able to go back to
default Power settings, but for now, SkimServ is stable again.

Please let us know if you see similar crashes in SkimServ after a Windows
Update, and if this work-around also works for you.

73,
Bob, N6TV

On Thu, Aug 16, 2018 at 1:40 AM, Bob Wilson, N6TV <n6tv at arrl.net> wrote:

> After working very reliably for months, my CW Skimmer Servers are now
> crashing every few hours, starting about 2 days ago, after a Windows 10
> service upgrade.  I'm running two Skimmers, from independent directories,
> using independent Red Pitayas (but the same disk and same gigabit switch to
> connect to them both to the same PC).
>
> The Windows Event Viewer, under Windows Logs, Application, shows a similar
> error each time:
>
> Faulting application name: SkimSrv2.exe, version: 1.6.0.145, time stamp:
> 0x2a425e19
> Faulting module name: ntdll.dll, version: 10.0.17134.228, time stamp:
> 0x2c71c7b8
> Exception code: 0xc0000005
> Fault offset: 0x00022e19
> Faulting process id: 0x890
> Faulting application start time: 0x01d4352a4ed8c491
> Faulting application path: C:\Program Files (x86)\Afreet\SkimSrv2\
> SkimSrv2.exe
> Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
> Report Id: 9b63df89-caba-4a8a-8163-c078fdeb2423
> Faulting package full name:
> Faulting package-relative application ID:
>
> The failure symptom is a pop-up window "Error writing to ...." , close
> that and one skimmer server goes away, but the other shows zero decoders
> and has to be restarted too.  Both seem to die at the same time.  Both are
> using CWSL_Tee.
>
> I think I received some private email from someone (N4ZR?) saying they
> were seeing the same thing, a month or so ago.
>
> Wonder if anyone else is seeing this now.  I have no idea how to fix
> this.  I tried running a Windows Update again and it found some things, but
> now it reports I am on the latest and there's nothing to upgrade.  SFC also
> found no errors.   I can't find any pattern to the failures, they just
> happen every few hours.
>
> In the Windows logs, before every failure, I see a many informational
> messages that all look like this:
>
> svchost (6780,G,98) The beta feature EseDiskFlushConsistency is enabled in
> ESENT due to the beta site mode settings 0x800000.
>
> But I don't know if that would have anything to do with this.  My C: drive
> is an SSD.
>
> The Red Pitayas are fine, they're not crashing.  I just have to keep
> restarting the Windows apps.  Of course I already tried rebooting
> everything but it didn't seem to help.
>
> 73,
> Bob, N6TV
>