Kernel stack trace for Winows 10 blue screen when running Cygwin?
Mon Aug 7 11:23:43 GMT 2023
On Aug 7 12:43, Cedric Blancher via Cygwin wrote:
> On Mon, 7 Aug 2023 at 11:55, Corinna Vinschen <firstname.lastname@example.org> wrote:
> > On Aug 7 11:29, Cedric Blancher via Cygwin wrote:
> > > Forwarding to email@example.com
> > >
> > > Honestly I find it deeply concerning that a plain, unprivileged user
> > > can Bluescreen a machine, and more so that it happens during normal
> > > Cygwin usage.
> > Same here. Cygwin is userspace only!
> > If any call in Cygwin can generate a bluescreen, it's a bug in the
> > kernel or in the driver. Naturally, we have neither control over the
> > kernel, nor over the NTFS driver. You might want to open a support case
> > with Microsoft.
> Well, a colleague is handling that. The feedback sent to her however was that:
> - Cygwin is not a Windows product
> - We should WSL instead
> - Cygwin might make use private Windows apis
> - We should run this by the "Cygwin company"
> It is my turn now to provide a kernel stack trace to prove them wrong
> - IF I can manage to make one. That's why I am asking for help here.
I'd start with running the crashing process under strace. This might
give a clue as to what or why it's happening. Be aware that an strace
might be *very* big in your case, and that running under strace might
take a *very* long time.
Apart from that, I'm not really familiar with catching OS kernel dumps,
but the dumper and minidumper tools in Cygwin might be of help, see the
More information about the Cygwin