On 5/1/2023 1:40 PM, Joel wrote:
> "...winston" <winstonmvp@gmail.com> wrote:
>> T wrote:
>>> On 4/28/23 09:50, ...winston wrote:
>>>>
>>>> As I and others have noted - the presence of artifacts on a display(or
>>>> even a spreadsheet) is not related to Fast Startup(on or off). Even if
>>>> the so called artifacts is/was resolved, by a Restart, Fast Startup
>>>> would still have no contribution to cause or effect.
>>>
>>> Fanbio
>>>
>> Meds not working?
>> Can't even spell a 6 letter word.
>>
>> Who knows maybe you meant artificial instead of artifacts.
>> That's the ticket, they weren't artifacts, it was some artificially
>> fixed by a Restart.
>
>
> T is blaming Windows for poor hardware failing.
>
No, T isn't doing that.

T is taking an adversarial approach to computer maintenance.

The last time I've seen honest-to-god artifacts, was
bad VRAM on a video card. But this was the conclusion
of the audience, rather than of a GPU designer. The
artifacts would include black circles plopped onto
the frame buffer image. Which suggests a functional unit
or a command processor that is capable of processing a
circle() call of some sort, was doing that. If the noise
was in a frame buffer storage area, this would show up as
"colored snow" in the image. Since there is no error
multiplication expected in a frame buffer.

The only artifacts I've seen from Terminal Services,
are black rectangles. These tend to be on various decorations,
rather than causing the entire window to go black.

The bash shell and WSLg, seem to use Terminal Services as
part of the graphics path. Yet, that path seems to be
artifact free (because all the data is local and kept
inside the machine, not send with packets on Ethernet or
Wifi). And whoever did that work, did a pretty good job.
The "quality" of the window decorations is not perfect,
yet the window itself functions just fine, better than
expected in fact. (The applications are running rootless
display.)

https://i.postimg.cc/Jn8SLn1G/WSLg-Terminal-Services-rootless-window-captured.gif

The SnippingTool picked the size of the capture. I did not
select that size, so it thinks there is some "spillover"
of pixels.

When hardware (or a hardware driver) fails, the artifacts
should not be picking favorites. If the artifacts are
in some software stack, you expect the symptoms to be more
localized.

Sometimes, you cannot take screenshots and capture the problem,
and you need an HDMI capture card to do it.

Paul

Joel wrote:
> "...winston" <winstonmvp@gmail.com> wrote:
>> T wrote:
>>> On 4/28/23 09:50, ...winston wrote:
>>>>
>>>> As I and others have noted - the presence of artifacts on a display(or
>>>> even a spreadsheet) is not related to Fast Startup(on or off). Even if
>>>> the so called artifacts is/was resolved, by a Restart, Fast Startup
>>>> would still have no contribution to cause or effect.
>>>
>>> Fanbio
>>>
>> Meds not working?
>> Can't even spell a 6 letter word.
>>
>> Who knows maybe you meant artificial instead of artifacts.
>> That's the ticket, they weren't artifacts, it was some artificially
>> fixed by a Restart.
>
>
> T is blaming Windows for poor hardware failing.
>

Not really.
Closer to having to troubleshoot a coincident event without any causal
relationship.

--
....w¡ñ§±¤ñ

On 5/1/23 12:17, Paul wrote:
> Sometimes, you cannot take screenshots and capture the problem,
> and you need an HDMI capture card to do it.
In my case, the customer took a picture of it with
her cell phone.
One of the great features of Go To Assist, if the
video card is failing, it does not show up on Go
To Assist.
My first thought was that it was a failing video
card (it was an on board video on the CPU).
But after disabling fast boot and doing a
hard reboot, the symptom could not be
reproduced.

On 5/1/23 10:40, Joel wrote:
>
> T is blaming Windows for poor hardware failing.

That is M$'s marketing department's excuse
for problems with Windows.

There is no reason why Windows, with professional
paid programmers, can not make their OS run on
the same cheaper hardware that unpaid volunteer
programmers on their own time, can make run
flawlessly on Linux.

T <T@invalid.invalid> wrote:

>> T is blaming Windows for poor hardware failing.
>
>That is M$'s marketing department's excuse
>for problems with Windows.
>
>There is no reason why Windows, with professional
>paid programmers, can not make their OS run on
>the same cheaper hardware that unpaid volunteer
>programmers on their own time, can make run
>flawlessly on Linux.

It just doesn't make sense that Microsoft would certify drivers for
hardware, that does work with open source drivers under Linux, but
fails to work under Windows itself. Your assertion needs evidence.

--
Joel Crump

T wrote:
> On 5/1/23 12:17, Paul wrote:
>> Sometimes, you cannot take screenshots and capture the problem,
>> and you need an HDMI capture card to do it.
>
> In my case, the customer took a picture of it with
> her cell phone.
>
> One of the great features of Go To Assist, if the
> video card is failing, it does not show up on Go
> To Assist.
>
> My first thought was that it was a failing video
> card (it was an on board video on the CPU).
> But after disabling fast boot and doing a
> hard reboot, the symptom could not be
> reproduced.
>
>
>
>
You(she) disabled Fast Start, not Fast Boot.
Repro requires re-enabling Fast Start and verifying the problem
re-appears. Until then, the cause/effect analysis(Fast Start/artifacts)
is false reasoning.

--
....w¡ñ§±¤ñ

On 5/3/2023 9:03 PM, T wrote:
> On 5/1/23 12:17, Paul wrote:
>> Sometimes, you cannot take screenshots and capture the problem,
>> and you need an HDMI capture card to do it.
>
> In my case, the customer took a picture of it with
> her cell phone.
>
> One of the great features of Go To Assist, if the
> video card is failing, it does not show up on Go
> To Assist.
>
> My first thought was that it was a failing video
> card (it was an on board video on the CPU).
> But after disabling fast boot and doing a
> hard reboot, the symptom could not be
> reproduced.

I can find graphics artifacts in a Google search,
when a user is playing a 3D game, the 3D game runs
in windowed mode, and it looks like the scan lines
used by the 3D window, influences 2D desktop areas
to the sides of the window. The pattern looks like
uninitialized memory, related to windows decorations
processing (the rounded corners on the windows and
the drop shadows, might be using part of the
graphics pipeline).

But this has nothing to do with your problem.

Google does have artifacts listed in a search.

*******

When the system starts up, the same thing happens whether
Fast Start is enabled or disabled. The video card
hardware registers have to be initialized.

You can move composited desktop windows around, without
generating Expose events. But Fast Start, does not have
any Applications running at the time, so there's nothing
to foul up there. (Only Hibernate has applications running
at startup.) In fact, there's a brand new desktop
session, a new Taskbar to draw and so on. All the "state"
of DWM, is going to be computed from scratch.

There is no particular reason for artifacts.

I would guess, that some hardware is not getting
reset properly, and something is out of reach
of the graphics initialization sequence.

Some modern computers now (like my Intel-based "Test Machine"),
they don't seem to have real hardware RESET on them. The
RESET seems to be emulated. I detected this one day, by
pressing RESET (hardware should respond in 0.5 to 1.0 seconds
or so), and the damn machine took 30 seconds before it got off
its hump and RESET. Real hardware RESET, cannot do that.
Real hardware RESET is absolute. It's the Hammer Of Thor
and cannot be ignored. This was always the very first issue
on the agenda during hardware design reviews at work, was
"whether your RESET really works".

Paul

On 5/4/23 09:07, Paul wrote:
> On 5/3/2023 9:03 PM, T wrote:
>> On 5/1/23 12:17, Paul wrote:
>>> Sometimes, you cannot take screenshots and capture the problem,
>>> and you need an HDMI capture card to do it.
>>
>> In my case, the customer took a picture of it with
>> her cell phone.
>>
>> One of the great features of Go To Assist, if the
>> video card is failing, it does not show up on Go
>> To Assist.
>>
>> My first thought was that it was a failing video
>> card (it was an on board video on the CPU).
>> But after disabling fast boot and doing a
>> hard reboot, the symptom could not be
>> reproduced.
>
> I can find graphics artifacts in a Google search,
> when a user is playing a 3D game, the 3D game runs
> in windowed mode, and it looks like the scan lines
> used by the 3D window, influences 2D desktop areas
> to the sides of the window. The pattern looks like
> uninitialized memory, related to windows decorations
> processing (the rounded corners on the windows and
> the drop shadows, might be using part of the
> graphics pipeline).
>
> But this has nothing to do with your problem.
>
> Google does have artifacts listed in a search.
>
> *******
>
> When the system starts up, the same thing happens whether
> Fast Start is enabled or disabled. The video card
> hardware registers have to be initialized.
>
> You can move composited desktop windows around, without
> generating Expose events. But Fast Start, does not have
> any Applications running at the time, so there's nothing
> to foul up there. (Only Hibernate has applications running
> at startup.) In fact, there's a brand new desktop
> session, a new Taskbar to draw and so on. All the "state"
> of DWM, is going to be computed from scratch.
>
> There is no particular reason for artifacts.
>
> I would guess, that some hardware is not getting
> reset properly, and something is out of reach
> of the graphics initialization sequence.
>
> Some modern computers now (like my Intel-based "Test Machine"),
> they don't seem to have real hardware RESET on them. The
> RESET seems to be emulated. I detected this one day, by
> pressing RESET (hardware should respond in 0.5 to 1.0 seconds
> or so), and the damn machine took 30 seconds before it got off
> its hump and RESET. Real hardware RESET, cannot do that.
> Real hardware RESET is absolute. It's the Hammer Of Thor
> and cannot be ignored. This was always the very first issue
> on the agenda during hardware design reviews at work, was
> "whether your RESET really works".
>
>     Paul

I can only replay what I saw. Perhaps
there was clutter in teh video memory?

On 5/3/23 21:35, ...winston wrote:
> T wrote:
>> On 5/1/23 12:17, Paul wrote:
>>> Sometimes, you cannot take screenshots and capture the problem,
>>> and you need an HDMI capture card to do it.
>>
>> In my case, the customer took a picture of it with
>> her cell phone.
>>
>> One of the great features of Go To Assist, if the
>> video card is failing, it does not show up on Go
>> To Assist.
>>
>> My first thought was that it was a failing video
>> card (it was an on board video on the CPU).
>> But after disabling fast boot and doing a
>> hard reboot, the symptom could not be
>> reproduced.
>>
>>
>>
>>
> You(she) disabled Fast Start, not Fast Boot.
> Repro requires re-enabling Fast Start and verifying the problem
> re-appears. Until then, the cause/effect analysis(Fast Start/artifacts)
> is false reasoning.
>

Fanboi

On 5/3/23 18:49, Joel wrote:
> T <T@invalid.invalid> wrote:
>
>>> T is blaming Windows for poor hardware failing.
>>
>> That is M$'s marketing department's excuse
>> for problems with Windows.
>>
>> There is no reason why Windows, with professional
>> paid programmers, can not make their OS run on
>> the same cheaper hardware that unpaid volunteer
>> programmers on their own time, can make run
>> flawlessly on Linux.
>
>
> It just doesn't make sense that Microsoft would certify drivers for
> hardware, that does work with open source drivers under Linux, but
> fails to work under Windows itself. Your assertion needs evidence.
>

I am confused by your question.

I little understanding of Linux maybe?

In Linux, the drivers come inside the kernel.
You can add them if you like, but I have not
had to do that for maybe 20 years now.

The kernels are gone over with a fine
toothed comb.

T <T@invalid.invalid> wrote:

>>>> T is blaming Windows for poor hardware failing.
>>>
>>> That is M$'s marketing department's excuse
>>> for problems with Windows.
>>>
>>> There is no reason why Windows, with professional
>>> paid programmers, can not make their OS run on
>>> the same cheaper hardware that unpaid volunteer
>>> programmers on their own time, can make run
>>> flawlessly on Linux.
>>
>> It just doesn't make sense that Microsoft would certify drivers for
>> hardware, that does work with open source drivers under Linux, but
>> fails to work under Windows itself. Your assertion needs evidence.
>
>I am confused by your question.
>
>I little understanding of Linux maybe?
>
>In Linux, the drivers come inside the kernel.
>You can add them if you like, but I have not
>had to do that for maybe 20 years now.
>
>The kernels are gone over with a fine
>toothed comb.

I mean that you would need to show more specifically how this has been
demonstrated to be the case.

--
Joel Crump

On 5/5/2023 12:58 PM, T wrote:

>
> I can only replay what I saw.  Perhaps
> there was clutter in teh video memory?

Power is shut off to it.

It would need some significant chunk of it, running
off +5VSB, and somehow I doubt they are doing that.

On an Intel system, the CPU has a GPU in it, the
I/O pipes are in the PCH (drive HDMI and DP from PCH).
The path from CPU to PCH is likely an uncommitted
digital bus (that is yet another flavor of GPU output
which is popular, and can drive Silicon Image HDMI output
devices). In a laptop, you could drive the
panel from LVDS on the PCH, as a flavor of crossbar
output.

This means the PCH needs to drive any output, according
to the output dimensions. A failure to do that correctly,
results in at least some panels reporting "Out of Range"
as a kind of artifact.

So on an Intel laptop, the graphics are partitioned into
two bits. The CPU housing has the "smart" bit in it.
The PCH (Southbridge) has the "dumb mechanical" piping
for LVDS, HDMI, DP. A failure to configure the
"dumb mechanical" bit properly, causes a certain class
of artifact to appear (such as "Out of Range" and blackness).
The firmware on the laptop, contains recorded info which
replaces the EDID on LCD monitors, and if you use the wrong
firmware, a portion of the panel has "black bars" because of it.

Paul

On 5/5/2023 1:01 PM, T wrote:
> On 5/3/23 18:49, Joel wrote:
>> T <T@invalid.invalid> wrote:
>>
>>>> T is blaming Windows for poor hardware failing.
>>>
>>> That is M$'s marketing department's excuse
>>> for problems with Windows.
>>>
>>> There is no reason why Windows, with professional
>>> paid programmers, can not make their OS run on
>>> the same cheaper hardware that unpaid volunteer
>>> programmers on their own time, can make run
>>> flawlessly on Linux.
>>
>>
>> It just doesn't make sense that Microsoft would certify drivers for
>> hardware, that does work with open source drivers under Linux, but
>> fails to work under Windows itself.  Your assertion needs evidence.
>>
>
>
> I am confused by your question.
>
> I little understanding of Linux maybe?
>
> In Linux, the drivers come inside the kernel.
> You can add them if you like, but I have not
> had to do that for maybe 20 years now.
>
> The kernels are gone over with a fine
> toothed comb.
>
>

In Mint 20.3 (fired up a few days ago), the Nouveau driver
is not capable of successfully bringing up my GTX 1080.
The NVidia driver does this correctly every time.

For the audience out there, the Nouveau driver is the
"FOSS effort" that does not use datasheets. The designers
reverse engineer stuff. Progress is very slow. Mistakes
are made.

To use NVidia means accepting a binary blob from the
manufacturer, which Linux is loathe to do (in an official way).
However, this does not prevent a number of distros from
having "convenient switches" to turn on the non-religion
(practical) option of video driver.

NVidia knows there is a hardware defect in the design
of the GPU on my card. That's why they have a watchdog,
the watchdog fires, the driver does a VPU recover,
the card comes up. Nouveau lacks this refinement.
Nouveau happily loses communication with the graphics
card, and it just... doesn't... care :-)

What's cool though, is if you set up a serial debug port
(do a Console over RS232, to a copy of Putty), you can
get it to work. And I mean, who among us here, does not
have an RS232 cable, right now, between their two computers.
"I know I do..." :-)

In place of "quiet splash" on the boot line, if you use

console=ttyS0,57600n8

then a second machine can display the console output
from Linux boot, on your copy of Putty terminal emulator
on the second machine. I am lucky, that the two computers
here, have a single RS232 port and a nine pin header on
the motherboard. I had to make up a custom cable to use
that puppy, just to give you some idea how easy this is
to do.

Now, I think the audience can see what Linux is all about :-)

This is what I have to put up with, as a multibooter
and taste tester. That's a "typical day" for me, when
testing random distros.

Paul

On 5/5/23 14:06, Paul wrote:
> On 5/5/2023 12:58 PM, T wrote:
>
>>
>> I can only replay what I saw.  Perhaps
>> there was clutter in teh video memory?
>
> Power is shut off to it.
>
> It would need some significant chunk of it, running
> off +5VSB, and somehow I doubt they are doing that.
>
> On an Intel system, the CPU has a GPU in it, the
> I/O pipes are in the PCH (drive HDMI and DP from PCH).
> The path from CPU to PCH is likely an uncommitted
> digital bus (that is yet another flavor of GPU output
> which is popular, and can drive Silicon Image HDMI output
> devices). In a laptop, you could drive the
> panel from LVDS on the PCH, as a flavor of crossbar
> output.
>
> This means the PCH needs to drive any output, according
> to the output dimensions. A failure to do that correctly,
> results in at least some panels reporting "Out of Range"
> as a kind of artifact.
>
> So on an Intel laptop, the graphics are partitioned into
> two bits. The CPU housing has the "smart" bit in it.
> The PCH (Southbridge) has the "dumb mechanical" piping
> for LVDS, HDMI, DP. A failure to configure the
> "dumb mechanical" bit properly, causes a certain class
> of artifact to appear (such as "Out of Range" and blackness).
> The firmware on the laptop, contains recorded info which
> replaces the EDID on LCD monitors, and if you use the wrong
> firmware, a portion of the panel has "black bars" because of it.
>
>    Paul

It was a desktop with a Intel CPU with graphic on it.

On 5/5/23 14:18, Paul wrote:
> On 5/5/2023 1:01 PM, T wrote:
>> On 5/3/23 18:49, Joel wrote:
>>> T <T@invalid.invalid> wrote:
>>>
>>>>> T is blaming Windows for poor hardware failing.
>>>>
>>>> That is M$'s marketing department's excuse
>>>> for problems with Windows.
>>>>
>>>> There is no reason why Windows, with professional
>>>> paid programmers, can not make their OS run on
>>>> the same cheaper hardware that unpaid volunteer
>>>> programmers on their own time, can make run
>>>> flawlessly on Linux.
>>>
>>>
>>> It just doesn't make sense that Microsoft would certify drivers for
>>> hardware, that does work with open source drivers under Linux, but
>>> fails to work under Windows itself.  Your assertion needs evidence.
>>>
>>
>>
>> I am confused by your question.
>>
>> I little understanding of Linux maybe?
>>
>> In Linux, the drivers come inside the kernel.
>> You can add them if you like, but I have not
>> had to do that for maybe 20 years now.
>>
>> The kernels are gone over with a fine
>> toothed comb.
>>
>>
>
> In Mint 20.3 (fired up a few days ago), the Nouveau driver
> is not capable of successfully bringing up my GTX 1080.
> The NVidia driver does this correctly every time.
>
> For the audience out there, the Nouveau driver is the
> "FOSS effort" that does not use datasheets. The designers
> reverse engineer stuff. Progress is very slow. Mistakes
> are made.
>
> To use NVidia means accepting a binary blob from the
> manufacturer, which Linux is loathe to do (in an official way).
> However, this does not prevent a number of distros from
> having "convenient switches" to turn on the non-religion
> (practical) option of video driver.
>
> NVidia knows there is a hardware defect in the design
> of the GPU on my card. That's why they have a watchdog,
> the watchdog fires, the driver does a VPU recover,
> the card comes up. Nouveau lacks this refinement.
> Nouveau happily loses communication with the graphics
> card, and it just... doesn't... care :-)
>
> What's cool though, is if you set up a serial debug port
> (do a Console over RS232, to a copy of Putty), you can
> get it to work. And I mean, who among us here, does not
> have an RS232 cable, right now, between their two computers.
> "I know I do..." :-)
>
> In place of "quiet splash" on the boot line, if you use
>
>    console=ttyS0,57600n8
>
> then a second machine can display the console output
> from Linux boot, on your copy of Putty terminal emulator
> on the second machine. I am lucky, that the two computers
> here, have a single RS232 port and a nine pin header on
> the motherboard. I had to make up a custom cable to use
> that puppy, just to give you some idea how easy this is
> to do.
>
> Now, I think the audience can see what Linux is all about :-)
>
> This is what I have to put up with, as a multibooter
> and taste tester. That's a "typical day" for me, when
> testing random distros.
>
>    Paul

You should consider using the better distro,
such as Mint, Ubooboo (for those that can't spell
Ubunto), and Fedora. With all the off, weird
distros, you are going to have nothing but problems.

On 5/5/23 10:46, Joel wrote:
> T <T@invalid.invalid> wrote:
>
>>>>> T is blaming Windows for poor hardware failing.
>>>>
>>>> That is M$'s marketing department's excuse
>>>> for problems with Windows.
>>>>
>>>> There is no reason why Windows, with professional
>>>> paid programmers, can not make their OS run on
>>>> the same cheaper hardware that unpaid volunteer
>>>> programmers on their own time, can make run
>>>> flawlessly on Linux.
>>>
>>> It just doesn't make sense that Microsoft would certify drivers for
>>> hardware, that does work with open source drivers under Linux, but
>>> fails to work under Windows itself. Your assertion needs evidence.
>>
>> I am confused by your question.
>>
>> I little understanding of Linux maybe?
>>
>> In Linux, the drivers come inside the kernel.
>> You can add them if you like, but I have not
>> had to do that for maybe 20 years now.
>>
>> The kernels are gone over with a fine
>> toothed comb.
>
>
> I mean that you would need to show more specifically how this has been
> demonstrated to be the case.
>

You could try asking that over on

test@lists.fedoraproject.org

On 5/5/23 15:37, T wrote:
> On 5/5/23 10:46, Joel wrote:
>> T <T@invalid.invalid> wrote:
>>
>>>>>> T is blaming Windows for poor hardware failing.
>>>>>
>>>>> That is M$'s marketing department's excuse
>>>>> for problems with Windows.
>>>>>
>>>>> There is no reason why Windows, with professional
>>>>> paid programmers, can not make their OS run on
>>>>> the same cheaper hardware that unpaid volunteer
>>>>> programmers on their own time, can make run
>>>>> flawlessly on Linux.
>>>>
>>>> It just doesn't make sense that Microsoft would certify drivers for
>>>> hardware, that does work with open source drivers under Linux, but
>>>> fails to work under Windows itself.  Your assertion needs evidence.
>>>
>>> I am confused by your question.
>>>
>>> I little understanding of Linux maybe?
>>>
>>> In Linux, the drivers come inside the kernel.
>>> You can add them if you like, but I have not
>>> had to do that for maybe 20 years now.
>>>
>>> The kernels are gone over with a fine
>>> toothed comb.
>>
>>
>> I mean that you would need to show more specifically how this has been
>> demonstrated to be the case.
>>
>
> You could try asking that over on
>
> test@lists.fedoraproject.org
Their archives are at
https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.org/
Maybe show one over there would give you
their testing guidelines.
From my experience with them, they do a
wonderful job.

T wrote:
> On 5/3/23 21:35, ...winston wrote:
>> T wrote:
>>> On 5/1/23 12:17, Paul wrote:
>>>> Sometimes, you cannot take screenshots and capture the problem,
>>>> and you need an HDMI capture card to do it.
>>>
>>> In my case, the customer took a picture of it with
>>> her cell phone.
>>>
>>> One of the great features of Go To Assist, if the
>>> video card is failing, it does not show up on Go
>>> To Assist.
>>>
>>> My first thought was that it was a failing video
>>> card (it was an on board video on the CPU).
>>> But after disabling fast boot and doing a
>>> hard reboot, the symptom could not be
>>> reproduced.
>>>
>>>
>>>
>>>
>> You(she) disabled Fast Start, not Fast Boot.
>> Repro requires re-enabling Fast Start and verifying the problem
>> re-appears. Until then, the cause/effect analysis(Fast
>> Start/artifacts) is false reasoning.
>>
>
>
> Fanboi
No matter how you look at...disabling Fast Start did not nor will it
ever fix artifacts.

But, since you have difficulty with being proven wrong on this(Fast
Start[not Fast Boot] disable fixed artifacts) from multiple
sources..your usual unprofessional approach is to sling mud, call names,
etc.

One of these days, you might learn how Windows really works. Hopefully
for you customers, that's sooner than later.

--
....w¡ñ§±¤ñ

On 5/6/23 00:02, ...winston wrote:
> T wrote:
>> On 5/3/23 21:35, ...winston wrote:
>>> T wrote:
>>>> On 5/1/23 12:17, Paul wrote:
>>>>> Sometimes, you cannot take screenshots and capture the problem,
>>>>> and you need an HDMI capture card to do it.
>>>>
>>>> In my case, the customer took a picture of it with
>>>> her cell phone.
>>>>
>>>> One of the great features of Go To Assist, if the
>>>> video card is failing, it does not show up on Go
>>>> To Assist.
>>>>
>>>> My first thought was that it was a failing video
>>>> card (it was an on board video on the CPU).
>>>> But after disabling fast boot and doing a
>>>> hard reboot, the symptom could not be
>>>> reproduced.
>>>>
>>>>
>>>>
>>>>
>>> You(she) disabled Fast Start, not Fast Boot.
>>> Repro requires re-enabling Fast Start and verifying the problem
>>> re-appears. Until then, the cause/effect analysis(Fast
>>> Start/artifacts) is false reasoning.
>>>
>>
>>
>> Fanboi
> No matter how you look at...disabling Fast Start did not nor will it
> ever fix artifacts.
>
> But, since you have difficulty with being proven wrong on this(Fast
> Start[not Fast Boot] disable fixed artifacts) from multiple
> sources..your usual unprofessional approach is to sling mud, call names,
> etc.
>
> One of these days, you might learn how Windows really works. Hopefully
> for you customers, that's sooner than later.
>

To quote you, no matter how you look at it, you were
not there and you did not do a binary dump of the
entire memory and a forensic analysis to find the
source of the artifacts.
When I disabled fast startup, did a hard reboot,
the artifacts went away and did not come back.
Case closed.
The analysis you did do was based on a the "assumption"
that everything was working normally in the OS
and that nothing was capable of writing to the
video memory.
By the way, I have written code to write directly
to video memory and the bit coin folks do this
all the time so I know this is possible. Especially
for corrupted code in the OS. But M$ sh**ty
code never corrupts, does it.
So, you have no freaking idea what actually caused
the artifacts, yet you claim superior knowledge.
How about next time you present your "speculations"
as just speculations and not hard fact.
So I repeat my analysis of your unsupported
assumption. You are a Fanbaoi. M$ can do no harm.

T wrote:
>
> So, you have no freaking idea what actually caused
> the artifacts, yet you claim superior knowledge.
>

As I've said before.

Disabling Fast Start doesn't(and will never) fix artifacts on a display
or spreadsheet.

Your statement that it did/implied it did - is and will always be false.

Paul and others have already explained potential causes, none of which
are related to Fast Start.

--
....w¡ñ§±¤ñ

On 5/6/23 10:24, ...winston wrote:
> T wrote:
>>
>> So, you have no freaking idea what actually caused
>> the artifacts, yet you claim superior knowledge.
>>
>
> As I've said before.
>
> Disabling Fast Start doesn't(and will never) fix artifacts on a display
> or spreadsheet.

Bull Shit. A corrupted OS can write crap to
video memory. Oh the pretty crap that shows
on your screen when you do so.

And Paul's explanations were well done as
probably causes. Your's, on the other hand,
stated things as unequivocal fact, when you
have no freaking clue what the actual cause was.

I do not either. I just now what stopped it.

Fanbio.

T <T@invalid.invalid> wrote:
> On 5/6/23 10:24, ...winston wrote:
> > T wrote:
> >>
> >> So, you have no freaking idea what actually caused
> >> the artifacts, yet you claim superior knowledge.
> >>
> >
> > As I've said before.
> >
> > Disabling Fast Start doesn't(and will never) fix artifacts on a display
> > or spreadsheet.
>
> Bull Shit. A corrupted OS can write crap to
> video memory. Oh the pretty crap that shows
> on your screen when you do so.
>
> And Paul's explanations were well done as
> probably causes. Your's, on the other hand,
> stated things as unequivocal fact, when you
> have no freaking clue what the actual cause was.
>
> I do not either. I just now what stopped it.

No, as I mentioned before, you failed Troublshooting 101.

You *think* you know what stopped it, but you did not *verify* that
what you *think* 'fixed' it, did *actually* fix it.

As we said, Troubleshooting 101.

> Fanbio.

I think you have an artifact on your display.

T wrote:
> On 5/6/23 10:24, ...winston wrote:
>> T wrote:
>>>
>>> So, you have no freaking idea what actually caused
>>> the artifacts, yet you claim superior knowledge.
>>>
>>
>> As I've said before.
>>
>> Disabling Fast Start doesn't(and will never) fix artifacts on a
>> display or spreadsheet.
>
> Bull Shit.   A corrupted OS can write crap to
> video memory.  Oh the pretty crap that shows
> on your screen when you do so.
>
> And Paul's explanations were well done as
> probably causes.  Your's, on the other hand,
> stated things as unequivocal fact, when you
> have no freaking clue what the actual cause was.
>
> I do not either.  I just now what stopped it.
>
> Fanbio.

Keep digging that hole.
Fast Start being disabled won't fix artifacts or a corrupted o/s.
I don't need to have a clue on the cause...but I do know that Fast Start
disabling will never fix the effect.

You, on the other hand...don't know what stopped it since it was never
turned back on by any means.

Your reasoning is akin to:
There's brown spots in the toilet
I turned off the heat(unrelated to the toilet or the spots), turned the
electrical supply breaker off, then on.
The brown spots disappeared.

--
....w¡ñ§±¤ñ

On 5/6/23 23:48, ...winston wrote:
> T wrote:
>> On 5/6/23 10:24, ...winston wrote:
>>> T wrote:
>>>>
>>>> So, you have no freaking idea what actually caused
>>>> the artifacts, yet you claim superior knowledge.
>>>>
>>>
>>> As I've said before.
>>>
>>> Disabling Fast Start doesn't(and will never) fix artifacts on a
>>> display or spreadsheet.
>>
>> Bull Shit.   A corrupted OS can write crap to
>> video memory.  Oh the pretty crap that shows
>> on your screen when you do so.
>>
>> And Paul's explanations were well done as
>> probably causes.  Your's, on the other hand,
>> stated things as unequivocal fact, when you
>> have no freaking clue what the actual cause was.
>>
>> I do not either.  I just now what stopped it.
>>
>> Fanbio.
>
> Keep digging that hole.
> Fast Start being disabled won't fix artifacts or a corrupted o/s.
> I don't need to have a clue on the cause...but I do know that Fast Start
> disabling will never fix the effect.
>
> You, on the other hand...don't know what stopped it since it was never
> turned back on by any means.
>
> Your reasoning is akin to:
> There's brown spots in the toilet
> I turned off the heat(unrelated to the toilet or the spots), turned the
> electrical supply breaker off, then on.
> The brown spots disappeared.
Keep at it fanbio. Your favorite software
vendor can do no harm.

On 07/05/2023 07:48, ...winston wrote:
>
> Keep digging that hole.
>
>
>
Can you stop responding to T. You can't force him or convince him that
his logic is defective. That's how some people are in this world. You
have to ignore them.