Weird problem with wallpaper in winnt 4.0

Crazybob · External Since: Oct 24, 2006 Posts: 8

I have a weird problem with Windows NT 4.0 SP6a concerning the
Wallpaper(background). My normal Wallpaper is earth_wt.bmp which is
confirmined in the registry. A good number of times when I log in it
brings up winnt256.bmp instead on the screen. When I right click on an
open part of the screen & do a properties it shows the Wallpaper set
at earth_wt.bmp as it should.

Why would Windows bring up the wrong Wallpaper on the screen? Has
anyone ever had this happen to you?

Bob

Calvin · External Since: Feb 23, 2004 Posts: 313

Hi CrazyBob,

It's funny you should mention this problem - I was seriously thinking of
adding it to the 'known bugs and limitations' page at NT$Ref here:

http://nt4ref.zcm.com.au/bugs.htm

I've seen this problem on a couple of machines I use, but was waiting to
see if anybody else independently found this problem to confirm it was
not just something I do wrong Razz

What I have found is that it is timing related. I don't know the _exact_
mechanism, but I do know that if you 'rush' the machine at bootup (ie:
login immediately the logon prompt appears, and while the hard drive is
still rattling away, presumably still loading and starting 'automatic'
devices and services) the problem is FAR more likely to surface.

It appears the user profile is being loaded, because all the other
elements of the profile are present (desktop icons, menus etc..) but the
attempt to read and load the wallpaper fails for some reason. (too much
traffic through the disk I/O system at the time?)

The solution is simple: logoff and log back on again and it gets it
right the next time around Razz

Calvin.

John John · External Since: Jun 05, 2004 Posts: 1937

Calvin wrote:

> Hi CrazyBob,
>
> It's funny you should mention this problem - I was seriously thinking of
> adding it to the 'known bugs and limitations' page at NT$Ref here:
>
> http://nt4ref.zcm.com.au/bugs.htm
>
> I've seen this problem on a couple of machines I use, but was waiting to
> see if anybody else independently found this problem to confirm it was
> not just something I do wrong Razz

>
> What I have found is that it is timing related. I don't know the _exact_
> mechanism, but I do know that if you 'rush' the machine at bootup (ie:
> login immediately the logon prompt appears, and while the hard drive is
> still rattling away, presumably still loading and starting 'automatic'
> devices and services) the problem is FAR more likely to surface.
>
> It appears the user profile is being loaded, because all the other
> elements of the profile are present (desktop icons, menus etc..) but the
> attempt to read and load the wallpaper fails for some reason. (too much
> traffic through the disk I/O system at the time?)
>
> The solution is simple: logoff and log back on again and it gets it
> right the next time around Razz

Make a batch file and execute it or run this at the RUN box or Command
Prompt and you should get the wallpaper without having to logout & login
again.

RunDll32.exe USER32.DLL,UpdatePerUserSystemParameters ,1 ,True

Maybe put the batch in the startup folder might work, but not sure based
on your observations the startup folder is probably processed before the
glitch happens.

John

Calvin · External Since: Feb 23, 2004 Posts: 313

PS:

1. Damn Shift key :-0 - that should be NT4Ref not NT$Ref - LOL

2. Other solution to problem, be a little patient at bootup, wait until
drive activity subsides, then logon - I've never seen the problem
happen this way.

3. Yet ANOTHER bug in Explorer.exe - I find it VERY interesting (and
highly supportive of my theory about bloat and instability) that the one
component of NT4 that is almost _directly_ inherited from the Win95/98
department is the component that is the biggest offender when it comes
to SILLY BUGS.

Calvin.

Calvin · External Since: Feb 23, 2004 Posts: 313

John John wrote:

> Make a batch file and execute it or run this at the RUN box or Command
> Prompt and you should get the wallpaper without having to logout & login
> again.
>
> RunDll32.exe USER32.DLL,UpdatePerUserSystemParameters ,1 ,True
>
> Maybe put the batch in the startup folder might work, but not sure based
> on your observations the startup folder is probably processed before the
> glitch happens.

Hi John,

Thanks for the suggestion. Where did you get the syntax of the RUNDLL32
call to do this ? Could be useful info there Smile

I think the simple solution is actually 'to have a little patience' - if
you let the machine settle before you login the problem NEVER happens
here - I'm only talking about waiting 20 or so seconds here, so it's no
biggy Smile

I'm used to turning the machine on and walking away for a few minutes
anyway - the full BIOS POST test for 512MB of RAM takes nearly 3 minutes
to run here. I know I could switch to the 'fast' test (which basically
does nothing more than 'size' the memory installed) but after having had
a Win2k box keel over spectacularly because of a RAM error that the
'quick' test failed to find, I'm happy to wait and know I have a system
with at least half-way decent testing of the RAM done first.

Calvin.

John John · External Since: Jun 05, 2004 Posts: 1937

Calvin wrote:

> John John wrote:
>
>> Make a batch file and execute it or run this at the RUN box or Command
>> Prompt and you should get the wallpaper without having to logout &
>> login again.
>>
>> RunDll32.exe USER32.DLL,UpdatePerUserSystemParameters ,1 ,True
>>
>> Maybe put the batch in the startup folder might work, but not sure
>> based on your observations the startup folder is probably processed
>> before the glitch happens.
>
>
> Hi John,
>
> Thanks for the suggestion. Where did you get the syntax of the RUNDLL32
> call to do this ? Could be useful info there Smile

Someone on another group was writing a little program to automatically
change wallpaper on their desktop at different time intervals. The
program was changing the wallpaper file in the HKCU registry key but
they couldn't get the wallpaper to change without a restart so they
asked for help. In my search for a solution I came upon this:

http://www.mail-archive.com/wine-devel@winehq.com/msg20786.html

and Dave Patrick gave us this one:

http://support.microsoft.com/dllhelp/?fid=204559&l=55&det=1

> I think the simple solution is actually 'to have a little patience' - if
> you let the machine settle before you login the problem NEVER happens
> here - I'm only talking about waiting 20 or so seconds here, so it's no
> biggy Smile

Another thing I am wondering with the problem at hand is; where is the
wallpaper file located? Is it in the winnt folder with the other winnt
and winnt256 bitmaps? Maybe the timing issue you observe might happen
if the files are in another folder?

John

Calvin · External Since: Feb 23, 2004 Posts: 313

John John wrote:

> Someone on another group was writing a little program to automatically
> change wallpaper on their desktop at different time intervals. The
> program was changing the wallpaper file in the HKCU registry key but
> they couldn't get the wallpaper to change without a restart so they
> asked for help. In my search for a solution I came upon this:
>
> http://www.mail-archive.com/wine-devel@winehq.com/msg20786.html
>
> and Dave Patrick gave us this one:
>
> http://support.microsoft.com/dllhelp/?fid=204559&l=55&det=1

Thanks for the links, will check it out !

> Another thing I am wondering with the problem at hand is; where is the
> wallpaper file located? Is it in the winnt folder with the other winnt
> and winnt256 bitmaps? Maybe the timing issue you observe might happen
> if the files are in another folder?

VERY good point - in my case YES, the wallpaper files are actually
located in a folder called (funilly enough) 'd:\wallpape.r\' (the style
allows the name to fit the 8.3 naming convention)

It may be that this problem only surfaces with the wallpaper in a folder
other than 'd:\winnt' - maybe CrazyBob can shed some light on this point Smile

Calvin.

Crazybob · External Since: Oct 24, 2006 Posts: 8

Calvin <nospam RemoveThis @spamcop.net> wrote:

>John John wrote:
>
>> Someone on another group was writing a little program to automatically
>> change wallpaper on their desktop at different time intervals. The
>> program was changing the wallpaper file in the HKCU registry key but
>> they couldn't get the wallpaper to change without a restart so they
>> asked for help. In my search for a solution I came upon this:
>>
>> http://www.mail-archive.com/wine-devel@winehq.com/msg20786.html
>>
>> and Dave Patrick gave us this one:
>>
>> http://support.microsoft.com/dllhelp/?fid=204559&l=55&det=1
>
>Thanks for the links, will check it out !
>
>> Another thing I am wondering with the problem at hand is; where is the
>> wallpaper file located? Is it in the winnt folder with the other winnt
>> and winnt256 bitmaps? Maybe the timing issue you observe might happen
>> if the files are in another folder?
>
>VERY good point - in my case YES, the wallpaper files are actually
>located in a folder called (funilly enough) 'd:\wallpape.r\' (the style
>allows the name to fit the 8.3 naming convention)
>
>It may be that this problem only surfaces with the wallpaper in a folder
>other than 'd:\winnt' - maybe CrazyBob can shed some light on this point Smile

>
>Calvin.

No the bitmap file is in the winnt directory.

Bob

John John · External Since: Jun 05, 2004 Posts: 1937

Crazybob wrote:

> Calvin <nospam.RemoveThis@spamcop.net> wrote:
>
>
>>John John wrote:
>>
>>
>>>Someone on another group was writing a little program to automatically
>>>change wallpaper on their desktop at different time intervals. The
>>>program was changing the wallpaper file in the HKCU registry key but
>>>they couldn't get the wallpaper to change without a restart so they
>>>asked for help. In my search for a solution I came upon this:
>>>
>>>http://www.mail-archive.com/wine-devel@winehq.com/msg20786.html
>>>
>>>and Dave Patrick gave us this one:
>>>
>>>http://support.microsoft.com/dllhelp/?fid=204559&l=55&det=1
>>
>>Thanks for the links, will check it out !
>>
>>
>>>Another thing I am wondering with the problem at hand is; where is the
>>>wallpaper file located? Is it in the winnt folder with the other winnt
>>>and winnt256 bitmaps? Maybe the timing issue you observe might happen
>>>if the files are in another folder?
>>
>>VERY good point - in my case YES, the wallpaper files are actually
>>located in a folder called (funilly enough) 'd:\wallpape.r\' (the style
>>allows the name to fit the 8.3 naming convention)
>>
>>It may be that this problem only surfaces with the wallpaper in a folder
>>other than 'd:\winnt' - maybe CrazyBob can shed some light on this point Smile

>>
>>Calvin.
>
>
> No the bitmap file is in the winnt directory.

Grasping at straws here... What hapens if you put it in:

C:\WINNT\Web\Wallpaper

John

Calvin · External Since: Feb 23, 2004 Posts: 313

> Calvin <nospam.DeleteThis@spamcop.net> wrote:

>>VERY good point - in my case YES, the wallpaper files are actually
>>located in a folder called (funilly enough) 'd:\wallpape.r\' (the style
>>allows the name to fit the 8.3 naming convention)
>>
>>It may be that this problem only surfaces with the wallpaper in a folder
>>other than 'd:\winnt' - maybe CrazyBob can shed some light on this point Smile

>>
>>Calvin.

Crazybob wrote:

> No the bitmap file is in the winnt directory.

Damn - another fine theory down the drain - LOL

It would appear the bug is real however - it's just the exact mechanism
we've yet to pin down.

Calvin.

Calvin · External Since: Feb 23, 2004 Posts: 313

Hey John,

Just noticed you seem to be transmitted a valid email address in your
newsgroup postings - probably wise if you 'mangle it' or in some other
way obscure it, lest the SPAM harvesting robots find you Sad

Calvin.

John John · External Since: Jun 05, 2004 Posts: 1937

e-mail me and see what happens.

John

Calvin wrote:
> Hey John,
>
> Just noticed you seem to be transmitted a valid email address in your
> newsgroup postings - probably wise if you 'mangle it' or in some other
> way obscure it, lest the SPAM harvesting robots find you Sad

>
> Calvin.

Calvin · External Since: Feb 23, 2004 Posts: 313

John John wrote:
> e-mail me and see what happens.

Hehehehehehe - point taken !

Calvin.

Crazybob · External Since: Oct 24, 2006 Posts: 8

I have been letting the system finish loading stuff & settling down
before logging in & I have not seen the problem since. Interesting???
Doesn't part of the registry get copied to a user specific part? Maybe
logging in to fast before it is copied due to a busy system causes
windows to grab the default wallpaper which I think is winnt256.bmp.
Just a thought.

Bob

Calvin <nospam DeleteThis @spamcop.net> wrote:

>PS:
>
>1. Damn Shift key :-0 - that should be NT4Ref not NT$Ref - LOL
>
>2. Other solution to problem, be a little patient at bootup, wait until
>drive activity subsides, then logon - I've never seen the problem
>happen this way.
>
>3. Yet ANOTHER bug in Explorer.exe - I find it VERY interesting (and
>highly supportive of my theory about bloat and instability) that the one
>component of NT4 that is almost _directly_ inherited from the Win95/98
>department is the component that is the biggest offender when it comes
>to SILLY BUGS.
>
>Calvin.

Calvin · External Since: Feb 23, 2004 Posts: 313

Hi Bob,

I'm glad to see my 'remedy' works for you Smile

Not ideal I know, but it
will do for the moment.

I'm not sure what is really happening here as to WHY the wallpaper
doesn't load - you are right however, the .default user wallpaper is set
to winnn256.bmp, so this probably how we wind up with it on our desktops !

The way the profile situation works is that the hive ntuser.dat from
your profile folder (eg: D:\winnt\profiles\username\ntuser.dat) is
copied into the registry tree as HKCurrentUser during a login, but the
weird thing is that all the other elements of the profile ARE working,
(ie: you start menu, you desktop icons and layout), so I'm left thinking
that the registry is correct, and it is the loading of wallpaper itself
that fails.

The other (vague) possibility is that when the HKCU registry is 'read'
to determine what wallpaper has been chosen, this key read fails,
producing the same results.

I'm certain it is a timing issue in any case.

The other weird thing is that this only seems to happen on SOME
machines, and I've never been able to see the element of commonality
linking them to cause this bug. (For a while there John's theory of a
wallpaper folder of other than \winnt looked promising, but you shot
that one down in flames !)

Calvin.