NVIDIA driver 391.xx breaks the system

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.

ken1943 wrote:
On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.

I would suspect bit locker. How would Nvidia know you are using it.
Also did you download the update and run the setup after bit locker is
running or disable it.

BitLocker generally requires two partitions.

A small (unencrypted) partition with no personal information in it,
is used for a bootstrap. You'd look for a .wim file in there,
which is the WinPE or similar used to start the booting process.
Some small amount of code is needed, to present a password
prompt or something along those lines. If you need to look
in System Reserved, you can always resort to TestDisk (if
you can figure out how to use it).

A small boot loader is required, before the BitLocker container
on C: can be unlocked. The "video driver" during that portion
of the process, could even be the Microsoft Basic Display Adapter
(inside the .wim), or the screen could even use the VESA driver.
(The black screen you can set up, with the OS choice in it, appears
to be VESA based.)

In other words, there is a "whole pile of innocuous stuff"
before drivers off encrypted C: are loaded. And that comes after
some amount of basic bootstrapping occurs with
the little System Reserved (or, whatever partition
is marked as the Active one - there are some
funny setups out there so you have to keep your
wits about you).

Additional variables include, the OP could have installed
an optional GOP flash image on the video card, which goes
hand-in-hand with UEFI boot, and takes the place of VESA.
And who knows what *additional* symptoms sets that can cause :-/

So if someone gets side-swiped by a driver like that, yes,
given a concerted effort, they can set a real trap for themselves,
and be the only person on the "suffering" list. I'm sure that
NVidia does their best to test all these configurations in their
lab, but testing costs money. And takes mountains of square
feet of floor space.

Paul

a.m wrote:
On Wed, 25 Apr 2018 10:27:31 -0600, ken1943
wrote:

On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.
I would suspect bit locker. How would Nvidia know you are using it.
Also did you download the update and run the setup after bit locker is
running or disable it.

I installed with Bitlocker enabled. I'm actually shocked that it would
have such tremendous issues because of the encryption system. I would
have expected such garbage from Linux but not Windows so much.

Do you have sufficient materials on hand to do A/B testing ?

Using a clean hard drive, install Windows without Bitlocker and
then install the questionable driver, and see what happens.

I can't really see how BitLocker figures into this. The volume is
either closed or open (with password entered), and so everything
should be working at that point.

Microsoft has a variety of defense mechanisms like ASLR, and is
constantly screwing around with stuff. Including compact
/compactOS:query and the like. There's a lot going on under the
hood, and not all of it has a GUI or obvious controls either.
Since January, there's been Meltdown/Spectre changes, things
added and removed. And this is why they have 7000 developers
working on Windows. And those 7000 developers have to
demonstrate to the boss "how they're indispensable".

For third-party developers, it's a wild ride. If you look
at how many releases of VirtualBox there were, during one
series of file format changes Microsoft made, it gives you
some idea the level of grief Microsoft is causing. I don't
see a reason why an NVidia developer isn't similarly affected.

I've had one event on the Test Machine here, where the kernel
entered a sleep state, and then proceeded to turn off the
power ("Dirty Shutdown"). One other poster has had multiple
of these. And the file involved in this case is the kernel,
and it's easy to lay the blame in that case.

So try a little fuzzing of your own, and see if you can
tip it upright again. Maybe with a little luck, you'll
get some clue delivered in EventViewer (where logs of
bad things happening go).

Paul

On Wed, 25 Apr 2018 10:23:55 -0600, ken1943
wrote:

On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.

Nvidia does have a forum. When I get updates for my cards, I only
update the driver, don't need the other stuff. There also is an option
to do a clean install of the update which I have used to clear any
possible problems.

I'm not sure whether they made a chaneg to how the drivers work but
it's shocking. I just installed 397.xx expecting that it wouldn't give
me the issues that 391.xx did. Instead, it caused the system to become
so unstable that I was convinced that the motherboard was dead or
something of the sort. It wouldn't even allow me to type a password at
the Bitlocker prompt without turning off the screen.

When I finally got back into the system, I uninstalled all of that
garbage and let Windows install the NVIDIA driver on its own. It's
outdated, but all of the issues enumerated above disappeared. It's
quite possible that everything I experienced has something to do with
Bitlocker though.

On Wed, 25 Apr 2018 10:27:31 -0600, ken1943
wrote:

On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.

I would suspect bit locker. How would Nvidia know you are using it.
Also did you download the update and run the setup after bit locker is
running or disable it.

I installed with Bitlocker enabled. I'm actually shocked that it would
have such tremendous issues because of the encryption system. I would
have expected such garbage from Linux but not Windows so much.

On Wed, 25 Apr 2018 13:41:04 -0400, Paul
wrote:

ken1943 wrote:
On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.

I would suspect bit locker. How would Nvidia know you are using it.
Also did you download the update and run the setup after bit locker is
running or disable it.

BitLocker generally requires two partitions.

A small (unencrypted) partition with no personal information in it,
is used for a bootstrap. You'd look for a .wim file in there,
which is the WinPE or similar used to start the booting process.
Some small amount of code is needed, to present a password
prompt or something along those lines. If you need to look
in System Reserved, you can always resort to TestDisk (if
you can figure out how to use it).

A small boot loader is required, before the BitLocker container
on C: can be unlocked. The "video driver" during that portion
of the process, could even be the Microsoft Basic Display Adapter
(inside the .wim), or the screen could even use the VESA driver.
(The black screen you can set up, with the OS choice in it, appears
to be VESA based.)

In other words, there is a "whole pile of innocuous stuff"
before drivers off encrypted C: are loaded. And that comes after
some amount of basic bootstrapping occurs with
the little System Reserved (or, whatever partition
is marked as the Active one - there are some
funny setups out there so you have to keep your
wits about you).

Additional variables include, the OP could have installed
an optional GOP flash image on the video card, which goes
hand-in-hand with UEFI boot, and takes the place of VESA.
And who knows what *additional* symptoms sets that can cause :-/

So if someone gets side-swiped by a driver like that, yes,
given a concerted effort, they can set a real trap for themselves,
and be the only person on the "suffering" list. I'm sure that
NVidia does their best to test all these configurations in their
lab, but testing costs money. And takes mountains of square
feet of floor space.

So I'd basically be better off disabling Bitlocker if I made it a
priority to keep the NVIDIA driver updated?

On Wed, 25 Apr 2018 18:33:56 -0400, Paul
wrote:

a.m wrote:
On Wed, 25 Apr 2018 10:27:31 -0600, ken1943
wrote:

On Wed, 25 Apr 2018 11:53:20 -0500, a.m wrote:

I'm not sure if anyone else has experienced this, but I notice that
every time I update my NVIDIA driver to the latest one, my system
basically becomes unusable. The display quickly turns off (even before
the system itself is loaded at the Bitlocker password prompt) and if
it does boot up, the screen either turns entirely green or completely
black and you have to force it off.

Using the worthless generic Microsoft display adapter causes no issue
and a previous version of the driver (382.xx) also seems to work
right.

Has _anyone_ experienced this? I'm shocked to find that no one else
seems to be reporting it through searches.
I would suspect bit locker. How would Nvidia know you are using it.
Also did you download the update and run the setup after bit locker is
running or disable it.

I installed with Bitlocker enabled. I'm actually shocked that it would
have such tremendous issues because of the encryption system. I would
have expected such garbage from Linux but not Windows so much.

Do you have sufficient materials on hand to do A/B testing ?

Using a clean hard drive, install Windows without Bitlocker and
then install the questionable driver, and see what happens.

I don't have a second computer to try it out on but I disabled
Bitlocker and am now in the process of installing the exact same
drivers which screwed up my machine. If things work, we'll know how
problematic Bitlocker can _potentially_ be in installing drivers
directly from the manufacturer for GPUs.

I can't really see how BitLocker figures into this. The volume is
either closed or open (with password entered), and so everything
should be working at that point.

I figured the exact same thing and that factors into why I was so
confused about how the machine reacted to the new drivers. It could
also be the result of some poor Windows update. After all, my wife had
the latest update cause Windows to boot into a black screen and it's
possible that the same update - which didn't do the exact same thing
to me - might have caused my machine to behave the way that it did.

Microsoft has a variety of defense mechanisms like ASLR, and is
constantly screwing around with stuff. Including compact
/compactOS:query and the like. There's a lot going on under the
hood, and not all of it has a GUI or obvious controls either.
Since January, there's been Meltdown/Spectre changes, things
added and removed. And this is why they have 7000 developers
working on Windows. And those 7000 developers have to
demonstrate to the boss "how they're indispensable".

For third-party developers, it's a wild ride. If you look
at how many releases of VirtualBox there were, during one
series of file format changes Microsoft made, it gives you
some idea the level of grief Microsoft is causing. I don't
see a reason why an NVidia developer isn't similarly affected.

I've had one event on the Test Machine here, where the kernel
entered a sleep state, and then proceeded to turn off the
power ("Dirty Shutdown"). One other poster has had multiple
of these. And the file involved in this case is the kernel,
and it's easy to lay the blame in that case.

So try a little fuzzing of your own, and see if you can
tip it upright again. Maybe with a little luck, you'll
get some clue delivered in EventViewer (where logs of
bad things happening go).

I'll let you know.