How to diagnose non-starting desktop?
Peter Weilbacher
starting, but hangs with the blue screen and the mouse pointer, i.e.
before any icons show up. There is no error message, it just hangs.
I already tried everything I could think of: use XWPs startup menu
(with shift pressed), use XFix from that, run checkini, use different
backed-up versions of the INI files, run with SET DESKTOP and without.
What would you do in such a case?
Some background: I replaced my old machine half a year ago with a new
one when this problem occurred. Before, I was using heavily customized
Desktops for me and my wife for years, starting them from slightly
different Config.sys files (basically, with different DESKTOP,
USER_INI, and SYSTEM_INI settings) via Recovery Choices menu. I have
been struggling since then to get them working, without success.
So I have been running the default Desktop that the eCS 2.0RCs
(currently: eCS 2.0 RC7) gave me after installation with just two or
three extra program objects. But it feels like running the system with
one hand tied behind my back and if I don't get "my" Desktop back with
all settings, program objects, and associations, I will probably dump
OS/2 rather soon.
Cheers,
Peter.
Ian Manners
The place you mention use to happen to me with an early version of
ACPI
on a multi AMD CPU PC. Had to give it a Ctrl-Alt-Del then cold boot it
a few
times before it would come good.
If I simply warm booted it it would always stop at the same spot, the
blue screen
with a mouse cursor but unable to do or start anything.
The latest ACPI drivers have fixed this problem.
My reading previously I think you said your replacement PC was AMD
SMP ?
What ACPI settings are you using in config.sys ?
I'm currently using only these :-
PSD=ACPI.PSD /SMP /APIC /R
BASEDEV=APM.ADD
and
@start /min c:\os2\AcpiDaemon.exe
and the end of startup.cmd
Cheers
Allan
> I am wondering what steps one should take when a Desktop is not
> starting, but hangs with the blue screen and the mouse pointer, i.e.
> before any icons show up. There is no error message, it just hangs.
>
> I already tried everything I could think of: use XWPs startup menu
> (with shift pressed), use XFix from that, run checkini, use different
> backed-up versions of the INI files, run with SET DESKTOP and without.
>
> What would you do in such a case?
This typically happens, when your (win) ini files gets destroyed.
Delete/rename :
\OS2\SYSTEM\USER.DAT
J:\OS2\SYSTEM\SYSTEM.DAT
If you can find an old working backup, that would of course
be nice
--
Allan.
It is better to close your mouth, and look like a fool,
than to open it, and remove all doubt.
Lars Erdmann
basic desktop (but PRESERVE them in basic desktop).
Then strip the EAs from your desktop (and save them away if you want)
and replace with EAs from basic desktop.
Some of your tuning will be lost (don't know exactly what) but that
should put you back into operation.
This does it all:
EAUTIL.EXE "C:\Basisarbeitsoberfl�che" "BaseDesktop.EAS" /S /R /P
EAUTIL.EXE "C:\Arbeitsoberfl�che" "SaveMyDesktop.EAS" /S /R (or rather:
the desktop directory that you want to use)
EAUTIL.EXE "C:\Arbeitsoberfl�che" "BaseDesktop.EAS" /J /O /P (or rather:
the desktop directory that you want to use)
Obviously you need to do that from a "F2" commandline.
P.S: the desktop directory you eventually want to use should have WPS ID
<WP_DESKTOP> (but I guess you know that already).
P.P.S: if you want to RENAME your desktop directory (say from
"C:\Arbeitsoberfl�che1" to "C:\Arbeitsoberfl�che") ALWAYS do that from
the WPS and NEVER directly from a commandline !!! The reason is that the
WPS object title and the directory name have to be changed in unison !
Lars
Peter Weilbacher schrieb:
Dave Yeo
>> What would you do in such a case?
> This typically happens, when your (win) ini files gets destroyed.
> Delete/rename :
> \OS2\SYSTEM\USER.DAT
> J:\OS2\SYSTEM\SYSTEM.DAT
> If you can find an old working backup, that would of course
> be nice
>
And of course running regedit2 will recreate the basic files (with just
printer and font entries IIRC)
Dave
Peter Brown
Peter Weilbacher wrote:
> I am wondering what steps one should take when a Desktop is not
> starting, but hangs with the blue screen and the mouse pointer, i.e.
> before any icons show up. There is no error message, it just hangs.
>
> I already tried everything I could think of: use XWPs startup menu
> (with shift pressed), use XFix from that, run checkini, use different
> backed-up versions of the INI files, run with SET DESKTOP and without.
>
> What would you do in such a case?
>
Here is what I did recently (as posted to the os2uk group):-
Hi All
I've been struggling to recover from a Desktop failing to startup; the
system was hanging just as the Desktop should start (expecting the
Startup sound to play) with hundreds of SYS3175's being written to the
popuplog.os2 file at every attempt to boot.
I think the problem stemmed from: I had been playing with system sound
settings when this Desktop had reset itself but failed to reappear
forcing me to finally press the Reset button as Ctrl-Alt-Del was not
working. I suspect this munged the mmpm.ini file - although I could not
see a problem with the file when using INIEditor while booted from
another installation. I had tried swapping out the OS2*.INI files for
earlier versions without any success before realising that the mmpm.ini
file could be responsible.
How I recovered this Desktop: I edited config.sys and changed SET
RUNWORKPLACE to L:\OS2\CMD.EXE and booted successfully to a cmd window
on a blue background. I then ran pmshell and was surprised that it
actually got to a working Desktop - without system sounds and File and
Print failed to start.
I ran System Setup -> Sound and Enabled sound. That worked.
I then had a look through IBMLAN.INI - looked fine - and PROTOCOL.INI
which also looked fine apart from the end-of-file marker in the text. I
deleted that, saved the file and then retried "Start File and Print
Client" which now worked.
I then edited config.sys to change SET RUNWORKPLACE back to
L:\OS2\PMSHELL.EXE and rebooted to a working Desktop with sound and peer
working.
I thought I'd post the above in case it is of possible future help to
anyone with a Desktop hanging at startup and the usual cure of replacing
current OS2*.INI files with backups has failed.
I do not know if your system has the same problem but maybe...
> Some background: I replaced my old machine half a year ago with a new
> one when this problem occurred. Before, I was using heavily customized
> Desktops for me and my wife for years, starting them from slightly
> different Config.sys files (basically, with different DESKTOP,
> USER_INI, and SYSTEM_INI settings) via Recovery Choices menu. I have
> been struggling since then to get them working, without success.
> So I have been running the default Desktop that the eCS 2.0RCs
> (currently: eCS 2.0 RC7) gave me after installation with just two or
> three extra program objects. But it feels like running the system with
> one hand tied behind my back and if I don't get "my" Desktop back with
> all settings, program objects, and associations, I will probably dump
> OS/2 rather soon.
>
> Cheers,
> Peter.
You may want to investigate using wps2rexx - on hobbes - at some time in
the future to provide a rexx backup of your Desktop in cmd files.
You can then modify the cmd files to (re)create required Desktop objects
on a new Desktop.
Regards
Pete
Allan
ok - I thought they were recreated by themselves - although Desktop
usually hangs on first reboot after deleting these files.
The good thing is, that it is only Odin and Innotek apps, that
uses these files, so normally it is not a big loss to delete them.
David T. Johnson
Thorolf Godawa
> Before, I was using heavily customized Desktops for me and
> my wife for years, starting them from slightly different
> Config.sys files (basically, with different DESKTOP,
> USER_INI, and SYSTEM_INI settings) via Recovery Choices menu.
the way I was going in the past to get all my desktop-settings and
objects transfered to a new system, was using the Rexx-script-features
of Object Desktop!
It will create a Rexx-script the creates all objects and all settings on
your desktop, before running it you can customize it, f.ex. it might be
necesarry to remove the standard-objects.
--
To Answer please replace "invalid" with "de" !
Zum Antworten bitte "invalid" durch "de" ersetzen !
Chau y hasta luego,
Thorolf
Peter Weilbacher
> I am wondering what steps one should take when a Desktop is not
> starting, but hangs with the blue screen and the mouse pointer, i.e.
> before any icons show up. There is no error message, it just hangs.
Guys, thanks for all your answers so far. I don't think any of them
apply, because all of the files involved did work before the system
upgrade. (I have implanted them on the new installation, or, vice-versa
added ACPI on my old installation to get it to boot. Same result on
both.) I'll try them anyway, just to make sure, that I haven't
overlooked anything.
But what I really wanted to know, is how to diagnose the problem.
On Linux I could read /var/log/Xorg.0.log for error messages. Is
there some way to get PMSHELL to log something? Or an external tool
that I could use to do that for PMSHELL or one of the DLLs that it
uses to load the WPS?
Cheers,
Peter.
Peter Weilbacher
> the way I was going in the past to get all my desktop-settings and
> objects transfered to a new system, was using the Rexx-script-features
> of Object Desktop!
>
> It will create a Rexx-script the creates all objects and all settings on
> your desktop, before running it you can customize it, f.ex. it might be
> necesarry to remove the standard-objects.
How can I used than when I cannot start the Desktop in question and I
don't have OD?
P.
Steven Levine
<news...@weilbacher.org> wrote:
Hi Peter,
> But what I really wanted to know, is how to diagnose the problem.
> On Linux I could read /var/log/Xorg.0.log for error messages. Is
> there some way to get PMSHELL to log something? Or an external tool
> that I could use to do that for PMSHELL or one of the DLLs that it
> uses to load the WPS?
I'm not entirely clear on how you transplanted the old Desktop and OS
install to the new system. Could you explain the steps you took?
Also, what was the base OS? In general, you should have been able to
transplant the existing volumes to the new hardware and, baring
hardware conflicts, boot and go.
Exactly where is the hang? Is it when the PM background color comes
up or when the WPS background color comes up?
PMMERGE does contain debug facilities, but first I need to better
understand where your hang is occurring.
Regards,
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Lars Erdmann
No there is no apparent and easy way but maybe you want to try this (at
least temporarily):
1.) You might want to try and replace RUNWORKPLACE with cmd.exe and
start pmshell.exe from there. Maybe it outputs something to stdout or
stderr but I don't know.
2.) You might want to try and output diagnosis info from PMDD.SYS (gives
pointer draw support to the used mouse driver, handles the single input
message queue) to a COM port:
DEVICE = c:\os2\boot\PMDD.SYS /Cn where n=1 for COM1 or n=2 for COM2
But as I said, at best these are temporary solutions.
Lars
Peter Weilbacher
> I'm not entirely clear on how you transplanted the old Desktop and OS
> install to the new system. Could you explain the steps you took?
> Also, what was the base OS? In general, you should have been able to
> transplant the existing volumes to the new hardware and, baring
> hardware conflicts, boot and go.
Yes, I just made the required volumes on the new HD and copied the stuff
over. (I don't remember how exactly, but it did leave the EAs intact.)
This was an installation of eCS 1.2 with FP4 (I think).
Then it turned out that my new system couldn't boot without ACPI, so I
added those files and Config.sys entries from eCS 2.0 rc6a.
When it hung, I then cleaned the system partition of everything,
installed eCS 2.0 (now rc7). Switching USER_INI/SYSTEM_INI I got the
same hang.
> Exactly where is the hang? Is it when the PM background color comes
> up or when the WPS background color comes up?
It is the first color I see after it switched into graphics mode. By
now I don't even remember any more what color I had set the WPS
background to. ;-)
> PMMERGE does contain debug facilities, but first I need to better
> understand where your hang is occurring.
That is good to hear.
Cheers,
Peter.
Peter Weilbacher
> 1.) You might want to try and replace RUNWORKPLACE with cmd.exe and
> start pmshell.exe from there. Maybe it outputs something to stdout or
> stderr but I don't know.
Never seen that happening, but yes, I'll try.
> 2.) You might want to try and output diagnosis info from PMDD.SYS (gives
> pointer draw support to the used mouse driver, handles the single input
> message queue) to a COM port:
> DEVICE = c:\os2\boot\PMDD.SYS /Cn where n=1 for COM1 or n=2 for COM2
No COM port on the new machine. And even if there was, I had nothing to
attach to the other end of the line. :-(
Peter.
Steven Levine
<news...@weilbacher.org> wrote:
Hi Peter,
> Yes, I just made the required volumes on the new HD and copied the stuff
> over. (I don't remember how exactly, but it did leave the EAs intact.)
As long as the EAs were copied and the INIs were clean and copied at
the same time, whatever you used was probably OK. Did you add any new
volumes yet?
How flexible is your test setup? Can to easily restore to a known
state from a backup?
> Then it turned out that my new system couldn't boot without ACPI, so I
> added those files and Config.sys entries from eCS 2.0 rc6a.
It probably would not hurt to upgrade the Dani drivers too.
> When it hung, I then cleaned the system partition of everything,
> installed eCS 2.0 (now rc7). Switching USER_INI/SYSTEM_INI I got the
> same hang.
Just switching the INIs is almost sure to fail, but not neccessarily
for the same reason. The WPS data in the INIs is tied to the WPS data
in the EAs.
FWIW, the last time I did a full install of the base OS on new laptop,
I used Object Desktop's Object Package feature. It includes script
that will package the entire Desktop. The package restore logic is
very capable and works better than Unimaint's portable backup/restore.
What I actually did was merge parts of two separate Desktops into the
base Desktop installed by eCS.
If you don't have a copy, there's a time limited demo on one of the
Warp Application Sampler CDs.
> It is the first color I see after it switched into graphics mode. By
> now I don't even remember any more what color I had set the WPS
> background to. ;-)
It could be hanging trying to initialize PM or during WPS startup. It
would be helpful to know. You should have CADH installed. Can you
use it to bring up a command line session? If so, we have a lot of
debugging options. I would start with pstat /c to see what is
currently running. Top might even provide some clues. If you have
any data you want me to look at just send it my way.
What else have you done to diagnose the problem? Have you tried
reverting to VGA in case it's a wierd video setting issue? Have you
tried a non-destructive makeini?
David T. Johnson
Allan
> It could be hanging trying to initialize PM or during WPS startup. It
> would be helpful to know. You should have CADH installed. Can you
> use it to bring up a command line session?
Most likely not, since CADH is started from Startup folder in WPS -
which is more or less the last app started at all.
Steven Levine
wrote:
Hi,
> Most likely not, since CADH is started from Startup folder in WPS -
> which is more or less the last app started at all.
Probably true. It's easy enough to tweak config.sys to start it from
there.
Another option is to Alt-F1 boot to the command line, start CADH and
run pmshell from the command line.
Peter Weilbacher
OK, finally some follow-up on all the advice that you have given me.
I now used the working eCS 2.0rc7 installation, again copied the
working Config.sys to \OS2\BOOT\Config.P. In that file I replaced
USER_INI and SYSTEM_INI and DESKTOP again to point to files of the
Desktop I really want. And I added lines to get WatchCat to be
available for tests.
- Replacing the EAs with those from the working Desktop or removing
them from the non-working desktop altogether didn't work.
- Removing the files from the Desktop directory didn't help.
- Removing \OS2\SYSTEM\{USER,SYSTEM}.DAT and using regedit2 to
recreate them or copying those files from my old installation
did not help.
- All the .ini files that Pete looked at seem intact. As they
are working for the other Desktop, I don't think this is relevant.
- What INI entry or other config corresponds to the switch
System Setup -> Sound and Enabled sound that helped Pete?
- The \MMOS2 directory is intact, it works beautifully on the other
Desktop. I don't think I ever used the startup sound.
- I am obviously using SMP files (kernel, DOSCALL1.DLL etc.) to
boot to the other desktop successfully. Removing ACPI from the
config causes my system to not boot any more. So to me that sounds
like I really need that for my computer.
- I set RUNWORKPLACE to cmd.exe. This booted fine. Starting pmshell
from that had no effect at all. I killed it again using WatchCat
but that didn't produce any output (not even with 2>&1 redirected).
- Dani drivers are the current version, I think:
$ type IBMS506$
R1.8.5
- When booting to CMD.EXE, I noticed something weird with the
titlebars. I found out that my old system used eStyler 1.0
(estlrl10.dll). As this eCS 2.0rc7 install has v1.1, I replaced
ESTLRL10 in OS2.INI -> SYS_DLLS -> LoadPerProcess with ESTLRL10
using regedit2. That seems to have helped the titlebar display
but had no effect at all on the WPS startup.
Now for the diagnostics:
- When booting using RUNWORKPLACE=pmshell the system hangs with the
wait-style mouse pointer at an otherwise black screen. The mouse
pointer can be moved.
- I have no idea how in this config I managed to replace the normal
blue startup screen with black, but as I said, it is the first
color I see.
- When activating WatchCat I can see that the PMSHELL.EXE process
marked FS is taking 99% CPU. None of its properties displayed
by WatchCat (Threads, DLLs, and Shared Memory) change.
- I append pstat /c output below that I get when using a command
line via WatchCat.
- If I boot with RUNWORKPLACE=cmd I see the same CPU usage of the
FS pmshell process.
My system is flexible enough for further tests, I hope. And I have
a backup of the system state before I replaced the old with the new
computer. The main limitation is my time...
Cheers,
Peter.
Process and Thread Information
Parent
Process Process Session Process Thread
ID ID ID Name ID Priority Block ID State
0026 0000 10 D:\OS2\USBMON.EXE 01 0200 08D0006A Block
02 0200 FD418A54 Block
0020 0000 01 D:\OS2\DRIVERS\SNAP\SDDDAEMN.EXE 01 0300 F93504DC Block
02 0300 FD5483F4 Block
03 0300 FD3A4D64 Block
04 0300 FD3A4978 Block
001E 0000 03 F:\UTILS\SYSTEM\WATCHCAT\WATCHCAT.EXE 01 031F
02 0300 FD58CA88 Block
03 031F FD6146F4 Block
04 031F FD5AE254 Block
05 0301 FFC2001E Block
0029 001E 03 D:\OS2\CMD.EXE 01 0301 FFC20029 Block
002A 0029 03 D:\OS2\PSTAT.EXE 01 0301 0B208C5D Running
001D 0000 00 F:\UTILS\SYSTEM\DRIVERS\ISOFS\ISOFSDMN.EXE 01 0410 FFFE0985 Block
001A 0000 00 D:\OS2\ACPIDAEMON.EXE 01 0200 FD3835D8 Block
0019 0000 00 D:\MMOS2\MMHELPDD.EXE 01 0200 FFF37AD8 Block
0018 0000 00 D:\MMOS2\MIDIDMON.EXE 01 031F 31E812B8 Block
0017 0000 00 D:\MPTN\BIN\DHCPCD.EXE 01 0200 FD5D0F18 Block
03 0200 FD5F27B4 Block
04 0200 00040017 Block
000F 0000 00 D:\MPTN\BIN\CNTRL.EXE 01 0304 FFF37AD8 Block
02 0304 F6BDAEC0 Block
03 0304 F6BDAE90 Block
04 0304 F6B0B380 Block
05 0304 F275002A Block
000E 0000 00 D:\IBMCOM\LANMSGEX.EXE 01 0200 FFFEF636 Block
000C 0000 00 D:\ECS\SYSTEM\GENMAC\DRIVER\HELPERW.EXE 01 0200 FFF37AD8 Block
02 021F 04F80192 Block
03 021F 00000000 Block
000A 0000 00 D:\OS2\SYSTEM\LVMALERT.EXE 01 0200 FFF37AD8 Block
0009 0000 00 D:\ECS\BIN\CACHEF32.EXE 01 0200 FFF37AD8 Block
02 031F 03E0E956 Block
03 0100 03E0EA36 Block
0001 0000 00 (kernel) 01 0100 FFEC59CC Block
02 031F F933F020 Block
03 031F F933F324 Block
04 031F F933F628 Block
05 031F F933F92C Block
06 0200 FFF361EA Block
07 0200 FFF0A89D Block
09 031E 0B00330C Block
001F 0001 01 D:\OS2\PMSHELL.EXE 01 0200 FD4E2DB4 Block
02 0300 055002E8 Block
03 0300 FFC2001F Block
04 0300 FFFD0029 Block
05 0300 FFFD002A Block
06 0300 0B002F0E Block
07 031E 0B003326 Block
08 0200 FD51530C Block
09 0200 FD5AE47C Block
0A 0200 08D00012 Block
0B 0200 FFF37AD8 Block
0C 0200 FFFE1114 Block
0D 0200 5262942E Block
0E 0200 FD4C0FAC Block
0F 0200 0D600319 Block
10 0200 FD69D7E8 Block
11 0200 FD69D7E8 Block
12 0200 FFFD0037 Block
13 0300 FFFE1228 Block
14 0300 FFFE1229 Block
15 0300 FFFE122A Block
16 0304 FFFD003B Block
17 0304 0B002F00 Block
18 0200 FFFD003D Block
19 0301 FFFE1251 Block
1A 0300 FFFE123F Block
1B 0200 FFC170E8 Block
1C 0400 FFC16F2C Block
1D 0200 FD383580 Block
0025 001F 11 D:\OS2\PMSHELL.EXE 01 0200 FD47CF58 Block
02 0300 FD4E2BC0 Block
03 030A FD4E2BA8 Block
04 0300 FD48D300 Block
05 0300 FD49E720 Block
06 0200 FD4E25B8 Block
07 0200 FD46B948 Block
08 0200 FD6D2EDC Block
09 0200 FD3EFEC8 Block
0A 0200 08D00096 Block
0B 0200 FD3C2DB8 Block
0C 021F 36800C00 Block
0D 0200 FFFE142E Block
0E 0200 FD3C2A18 Block
0F 0200 FD3C2A60 Block
0024 001F 10 D:\OS2\PMSPOOL.EXE 01 0200 FFF37AD8 Block
02 0200 FD47C954 Block
03 0200 3638000E Block
04 0200 FD47C944 Block
05 0200 FD47C92C Block
06 0200 FD49E610 Block
07 0200 FD49E6A8 Block
08 0200 FD44DFF0 Block
09 0200 FD44CE24 Block
0022 001F 00 D:\OS2\SYSTEM\HARDERR.EXE 01 0300 0B002F2A Block
02 0300 0B00323E Block
03 0300 0B00324C Block
0021 001F FF0 VDM 01 0300 FD537A34 Block
Peter Brown
Peter Weilbacher wrote:
> On 01/11/09 11:44, Peter Weilbacher wrote:
>> What would you do in such a case?
>
> OK, finally some follow-up on all the advice that you have given me.
>
> I now used the working eCS 2.0rc7 installation, again copied the
> working Config.sys to \OS2\BOOT\Config.P. In that file I replaced
> USER_INI and SYSTEM_INI and DESKTOP again to point to files of the
> Desktop I really want. And I added lines to get WatchCat to be
> available for tests.
>
> - Replacing the EAs with those from the working Desktop or removing
> them from the non-working desktop altogether didn't work.
> - Removing the files from the Desktop directory didn't help.
> - Removing \OS2\SYSTEM\{USER,SYSTEM}.DAT and using regedit2 to
> recreate them or copying those files from my old installation
> did not help.
> - All the .ini files that Pete looked at seem intact. As they
> are working for the other Desktop, I don't think this is relevant.
> - What INI entry or other config corresponds to the switch
> System Setup -> Sound and Enabled sound that helped Pete?
File: \mmos2\mmpm.ini
Application: MMPM2_Alarm_Sounds_Data
Key: EnableSounds
> - The \MMOS2 directory is intact, it works beautifully on the other
> Desktop. I don't think I ever used the startup sound.
> - I am obviously using SMP files (kernel, DOSCALL1.DLL etc.) to
> boot to the other desktop successfully. Removing ACPI from the
> config causes my system to not boot any more. So to me that sounds
> like I really need that for my computer.
> - I set RUNWORKPLACE to cmd.exe. This booted fine. Starting pmshell
> from that had no effect at all. I killed it again using WatchCat
> but that didn't produce any output (not even with 2>&1 redirected).
> - Dani drivers are the current version, I think:
> $ type IBMS506$
> R1.8.5
> - When booting to CMD.EXE, I noticed something weird with the
> titlebars. I found out that my old system used eStyler 1.0
> (estlrl10.dll). As this eCS 2.0rc7 install has v1.1, I replaced
> ESTLRL10 in OS2.INI -> SYS_DLLS -> LoadPerProcess with ESTLRL10
> using regedit2. That seems to have helped the titlebar display
> but had no effect at all on the WPS startup.
>
> Now for the diagnostics:
> - When booting using RUNWORKPLACE=pmshell the system hangs with the
> wait-style mouse pointer at an otherwise black screen. The mouse
> pointer can be moved.
That sounds like the desktop background is not loading...
Did you have the standard RC7 background image?
If "Yes" have you installed IFE2.60 in preference to the ecs supplied 2.40?
If "Yes" that problem is simply that after installing IFE2.60 the
following eCS bitmaps fail to display (Bug Reported):-
ecodesk.bmp, ecs20bgo.bmp, ecs20rc7.bmp
> - I have no idea how in this config I managed to replace the normal
> blue startup screen with black, but as I said, it is the first
> color I see.
The above may be the answer.
Sorry to not be more helpful...
Pete
Marty
> On 01/11/09 11:44, Peter Weilbacher wrote:
>> What would you do in such a case?
>
> OK, finally some follow-up on all the advice that you have given me.
>
> I now used the working eCS 2.0rc7 installation, again copied the
> working Config.sys to \OS2\BOOT\Config.P. In that file I replaced
> USER_INI and SYSTEM_INI and DESKTOP again to point to files of the
> Desktop I really want. And I added lines to get WatchCat to be
> available for tests.
It definitely sounds like your INIs are pointing to things that don't
exist on your system. Just copying EAs doesn't install the classes on
your system that were on the other one. So things like eStyler,
multimedia, XWorkplace, etc., will cause you problems. Your INI files
are telling the WPS to create objects out of classes that it can't find.
You need to rebuild your INIs from scratch. Run \os2\MAKEINI.EXE and
pick an appropriate *.RC file as a seed. This will create a rudimentary
desktop containing only classes that you have installed on your system.
Once you get that up and running, you can worry about transferring your
other objects across. Good luck.
--
Reverse the parts of the e-mail address to reply by mail.
Steven Levine
<news...@weilbacher.org> wrote:
> I now used the working eCS 2.0rc7 installation, again copied the
> working Config.sys to \OS2\BOOT\Config.P. In that file I replaced
> USER_INI and SYSTEM_INI and DESKTOP again to point to files of the
> Desktop I really want. And I added lines to get WatchCat to be
> available for tests.
Unfortunately, this is extremely unlikely to work. Consider all the
file system objects that live outside the Desktop. By replacing the
INIs, you have orphaned a number of object and installed object
handles that point to objects that no longer exist.
There's only a few applications I know of that can merge desktops.
Object Desktop's object packages have worked the best for me.
Unimaint's portable restore is there, but I've only had partial
success with it. Deskman was supposed to have a portable Desktop
restore, but I've never used it.
When you say your restored the EAs, how did you do this?
> - I set RUNWORKPLACE to cmd.exe. This booted fine. Starting pmshell
> from that had no effect at all. I killed it again using WatchCat
> but that didn't produce any output (not even with 2>&1 redirected).
So you can run with
PROTSHELL=\OS2\PMSHELL.EXE
This implies that the PM subsystem is coming up? You should be able
to switch to the PM session, which should be the PM background color.
When debugging WPS startup you want to use something similar to the
following
SET RUNWORKPLACE=\USR\BIN\4OS2.EXE
SET RESTARTOBJECTS=NO
SET SHELLEXCEPTIONHANDLER=OFF
SET SHAPIEXCEPTIONHANDLER=OFF
The last two prevent the WPS from hiding exceptions.
See the debugging section of WPSGUIDE.INF. Search for IPMD. If PM is
otherwise OK, you can use icsdebug, sd386 or OpenWatcom's wd.exe to
find out where pmshell is dieing.
> ESTLRL10 in OS2.INI -> SYS_DLLS -> LoadPerProcess with ESTLRL10
> using regedit2. That seems to have helped the titlebar display
> but had no effect at all on the WPS startup.
I would not expect it to.
> Now for the diagnostics:
> - When booting using RUNWORKPLACE=pmshell the system hangs with the
> wait-style mouse pointer at an otherwise black screen. The mouse
> pointer can be moved.
I would say that the WPS is dieing before it can even clear the screen
to the background color.
> - When activating WatchCat I can see that the PMSHELL.EXE process
> marked FS is taking 99% CPU.
Both pmshell instances It should be PM sessions. Take a look at a
running setup to see what is typical.
> My system is flexible enough for further tests, I hope. And I have
> a backup of the system state before I replaced the old with the new
> computer. The main limitation is my time...
It's always that way. I would really like to restart building
Seamonkey here, but I just don't seem to have any free time.
There is one thing you can try that I have never tested here. Since
the first instance of pmshell appears to be running OK, you might be
able to run checkini in the full screen session. If it runs, it might
provide some clues.
David T. Johnson
Jack Troughton
> On 01/11/09 11:44, Peter Weilbacher wrote:
>> What would you do in such a case?
>
> OK, finally some follow-up on all the advice that you have given me.
>
> I now used the working eCS 2.0rc7 installation, again copied the working
> Config.sys to \OS2\BOOT\Config.P. In that file I replaced USER_INI and
> SYSTEM_INI and DESKTOP again to point to files of the Desktop I really
> want. And I added lines to get WatchCat to be available for tests.
You're actually going about this a little backwards.
What you should try to do is to take a complete backup of the system you
wish to transfer to the new machine and put it on a disk in the new
machine. If you are doing this as part of upgrading your system, upgrade
it on the old machine and then transfer it to the new machine. At that
point, your ini files will all be fine... what you will have to do
instead is to deal with any driver changes etc that may be required on
the new hardware. I've not done this in many years, but in my experience
you'll find that surprisingly little will need to be done in that regard.
You might want to run the snoop part of the install again so it can find
any new hardware with new driver requirements.
So, instead of installing on the new machine and then transferring the
desktop, upgrade/update the old machine and then transfer the entire
system to the new machine.
Your main problem is almost certainly due to replaced classes on the old
machine that don't have the class libraries on the new machine.
An alternative approach might be to try xcopying the old system over the
new one, making sure that you don't overwrite any of the new system's
files, and THEN replacing the inis etc. I think the switches would be
xcopy /h/t/s/e/r/v (no /o as that overwrites existing target files)...
but do go through the help on xcopy to make sure the switches are the
ones you want.. This should move your class libraries (er, those'd be dll
files) over to the new system whilst maintaining the new DLLs that
shipped with the new system.
It's been quite a while since I did any of this stuff, so take it with a
large block of salt... but I think the main point to take away is that
I'm pretty sure your fundamental procedure is wrong, and you need to
rethink it. Usually, what I did in situations like this was to put in a
new system, copy the apps and data into place on it, and then just create
the relevant program objects and shortcuts to the various things you
want. Desktop enhancers however always need to be reinstalled....
Cheers,
Jack
Marty
> Your main problem is almost certainly due to replaced classes on the old
> machine that don't have the class libraries on the new machine.
I agree.
> An alternative approach might be to try xcopying the old system over the
> new one, making sure that you don't overwrite any of the new system's
> files, and THEN replacing the inis etc. I think the switches would be
> xcopy /h/t/s/e/r/v (no /o as that overwrites existing target files)...
> but do go through the help on xcopy to make sure the switches are the
> ones you want.. This should move your class libraries (er, those'd be dll
> files) over to the new system whilst maintaining the new DLLs that
> shipped with the new system.
That won't do it. He also needs to copy the *.IR files in os2\etc to
get the classes registered in the system, which will already exist in
the new system, just lacking some information possibly. He'll need to
replace those and copy the SET SOMIR=... statement from his old config.sys.
Peter Weilbacher
> It definitely sounds like your INIs are pointing to things that don't
> exist on your system. Just copying EAs doesn't install the classes on
> your system that were on the other one. So things like eStyler,
> multimedia, XWorkplace, etc., will cause you problems. Your INI files
> are telling the WPS to create objects out of classes that it can't find.
I'm not sure why you say that. The WPS is very fault tolerant and you
can have all kinds of rubbish in your INIs without getting problems.
Classes that are installed but have their DLL missing are simply ignored,
as are files that are no longer there but still exist as an object
handle in the INI(s). (It's just that once there are too many left, the
files get too big and the shared RAM problems become more apparent.)
> You need to rebuild your INIs from scratch. Run \os2\MAKEINI.EXE and
> pick an appropriate *.RC file as a seed. This will create a rudimentary
> desktop containing only classes that you have installed on your system.
> Once you get that up and running, you can worry about transferring your
> other objects across. Good luck.
I guess you didn't read all of my posts in this thread. I have a working
system (the eCS 2.0rc7 install). And if I really have to create a new
desktop I can do so under Linux or some other OS which has a better
long-term perspective.
Cheers,
Peter.
Peter Weilbacher
> On Sat, 7 Nov 2009 14:48:52 UTC, Peter Weilbacher
> <news...@weilbacher.org> wrote:
>
>> I now used the working eCS 2.0rc7 installation, again copied the
>> working Config.sys to \OS2\BOOT\Config.P. In that file I replaced
>> USER_INI and SYSTEM_INI and DESKTOP again to point to files of the
>> Desktop I really want. And I added lines to get WatchCat to be
>> available for tests.
>
> Unfortunately, this is extremely unlikely to work. Consider all the
> file system objects that live outside the Desktop. By replacing the
> INIs, you have orphaned a number of object and installed object
> handles that point to objects that no longer exist.
See my answer to Marty. This should not matter. (And I have restored
two desktops through numerous system upgrades this way.)
> When you say your restored the EAs, how did you do this?
I followed Lars' recipe (and again confirmed it reading the eautil
help page).
> When debugging WPS startup you want to use something similar to the
> following
>
> SET RUNWORKPLACE=\USR\BIN\4OS2.EXE
> SET RESTARTOBJECTS=NO
> SET SHELLEXCEPTIONHANDLER=OFF
> SET SHAPIEXCEPTIONHANDLER=OFF
>
> The last two prevent the WPS from hiding exceptions.
>
> See the debugging section of WPSGUIDE.INF. Search for IPMD. If PM is
> otherwise OK, you can use icsdebug, sd386 or OpenWatcom's wd.exe to
> find out where pmshell is dieing.
Aha, that at least got me somewhere. I used IDebug, which put me
somewhere into code from PMWP.DLL. Just that I only see assembler
without any function names, so it doesn't really help.
>> ESTLRL10 in OS2.INI -> SYS_DLLS -> LoadPerProcess with ESTLRL10
>> using regedit2. That seems to have helped the titlebar display
>> but had no effect at all on the WPS startup.
>
> I would not expect it to.
>
>> Now for the diagnostics:
>> - When booting using RUNWORKPLACE=pmshell the system hangs with the
>> wait-style mouse pointer at an otherwise black screen. The mouse
>> pointer can be moved.
>
> I would say that the WPS is dieing before it can even clear the screen
> to the background color.
>
>> - When activating WatchCat I can see that the PMSHELL.EXE process
>> marked FS is taking 99% CPU.
>
> Both pmshell instances It should be PM sessions. Take a look at a
> running setup to see what is typical.
No, the first is always FS. And has been in any OS/2 installation as
far back as I can remember.
> There is one thing you can try that I have never tested here. Since
> the first instance of pmshell appears to be running OK, you might be
> able to run checkini in the full screen session. If it runs, it might
> provide some clues.
No, that couldn't find the desktop. Even with the D<path> parameter
it told me that it couldn't find D<path>. ;-)
I wanted to post the above already two days ago. Since then I found out
that if I activate WatchCat (pressing Ctrl-Alt-W) while the second
pmshell process seems to hang (the one that I start from the CMD shell),
WatchCat somehow triggers something in pmshell and the WPS indeed starts.
It is still very unstable, though, but I managed to run checkini twice.
Now, if I start any program from a program object or open a WPS folder,
the whole system freezes again.
More, once I get on with this.
Cheers,
Peter.
Peter Weilbacher
> What you should try to do is to take a complete backup of the system you
> wish to transfer to the new machine and put it on a disk in the new
> machine. If you are doing this as part of upgrading your system, upgrade
> it on the old machine and then transfer it to the new machine. At that
> point, your ini files will all be fine...
This is what I tried first half a year ago (and a few times since then),
and it wasn't fine at all. Exactly the same problem as with this
"backwards" approach.
P.
Marty
> On 07/11/09 21:38, Marty wrote:
>
>> It definitely sounds like your INIs are pointing to things that don't
>> exist on your system. Just copying EAs doesn't install the classes on
>> your system that were on the other one. So things like eStyler,
>> multimedia, XWorkplace, etc., will cause you problems. Your INI files
>> are telling the WPS to create objects out of classes that it can't find.
>
> I'm not sure why you say that. The WPS is very fault tolerant and you
> can have all kinds of rubbish in your INIs without getting problems.
> Classes that are installed but have their DLL missing are simply ignored,
> as are files that are no longer there but still exist as an object
> handle in the INI(s). (It's just that once there are too many left, the
> files get too big and the shared RAM problems become more apparent.)
Some extenders will re-assign the classes of critical objects though,
right? For example, XFolder?
>> You need to rebuild your INIs from scratch. Run \os2\MAKEINI.EXE and
>> pick an appropriate *.RC file as a seed. This will create a rudimentary
>> desktop containing only classes that you have installed on your system.
>> Once you get that up and running, you can worry about transferring your
>> other objects across. Good luck.
>
> I guess you didn't read all of my posts in this thread. I have a working
> system (the eCS 2.0rc7 install). And if I really have to create a new
> desktop I can do so under Linux or some other OS which has a better
> long-term perspective.
What exactly are you trying to recover here then? Basically anything
with physical data associated with it exists as a file containing that
data. Do you have so many abstract objects that are difficult to
re-create? When I had a problem like this in the past, I just took it
on the chin that I was going to lose my intangible objects, but it
wasn't that big of a loss. Just curious (not a particularly
relevant/helpful line of questioning, to be sure).
Steven Levine
<news...@weilbacher.org> wrote:
Hi Peter,
> I followed Lars' recipe (and again confirmed it reading the eautil
> help page).
Lars recipe is fine if you are trying to recover from the case where
the WPS get confused decides to create a new Desktop folder with a
numerical suffix on the name. This is the same kind of failure the
results in multiple Nowhere folders. In my experience, it's not going
to allow you to transplant your old Desktop into a new install. What
will work to a certain level is code like what Unimaint generates. To
backup it is
"F:\OS2\ATTRIB.EXE" -S -H "F:\OS2\OS2.INI"
"F:\OS2\ATTRIB.EXE" -S -H "F:\OS2\OS2SYS.INI"
IF EXIST "D:\UNIMAINT\BKUP\SYSBIN01.ZIP" ERASE
"D:\UNIMAINT\BKUP\SYSBIN01.ZIP"
IF EXIST "D:\UNIMAINT\BKUP\SYSBDR01.ZIP" ERASE
"D:\UNIMAINT\BKUP\SYSBDR01.ZIP"
IF EXIST "D:\UNIMAINT\BKUP\SYSWC01.ZIP" ERASE
"D:\UNIMAINT\BKUP\SYSWC01.ZIP"
"D:\UNIMAINT\ZIP.EXE" "D:\UNIMAINT\BKUP\SYSBIN01" "F:\OS2\OS2.INI"
"D:\UNIMAINT\ZIP.EXE" "D:\UNIMAINT\BKUP\SYSBIN01" "F:\OS2\OS2SYS.INI"
"D:\UNIMAINT\ZIP.EXE" -r -S "D:\UNIMAINT\BKUP\SYSBDR01" "F:\Desktop"
"D:\UNIMAINT\ZIP.EXE" -j "D:\UNIMAINT\BKUP\SYSWC01"
"F:\OS2\DLL\DOCK*.CFG"
"D:\UNIMAINT\ZIP.EXE" -j "D:\UNIMAINT\BKUP\SYSWC01"
"F:\OS2\DLL\SCENTER.CFG"
"D:\UNIMAINT\ZIP.EXE" "D:\UNIMAINT\BKUP\SYSBCK01"
"D:\UNIMAINT\BKUP\SYSBIN01.ZIP"
"D:\UNIMAINT\ZIP.EXE" "D:\UNIMAINT\BKUP\SYSBCK01"
"D:\UNIMAINT\BKUP\SYSBDR01.ZIP"
"D:\UNIMAINT\ZIP.EXE" "D:\UNIMAINT\BKUP\SYSBCK01"
"D:\UNIMAINT\BKUP\SYSWC01.ZIP"
ERASE "D:\UNIMAINT\BKUP\SYSWC01.ZIP"
ERASE "D:\UNIMAINT\BKUP\SYSBIN01.ZIP"
ERASE "D:\UNIMAINT\BKUP\SYSBDR01.ZIP"
"F:\OS2\ATTRIB.EXE" +S "F:\OS2\OS2.INI"
"F:\OS2\ATTRIB.EXE" +S "F:\OS2\OS2SYS.INI"
Note that both the INIs and the Desktop directory tree get saved.
This code can be simplified. Unimaint does it this way for historical
reasons.
To restore, the process is reversed.
"D:\UNIMAINT\INICLEAN.EXE" -i"F:\Desktop"
"F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2.INI"
"F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2SYS.INI"
ERASE "F:\OS2\OS2.INI"
ERASE "F:\OS2\OS2SYS.INI"
"D:\UNIMAINT\UNZIP.EXE" -j "D:\UNIMAINT\BKUP\SYSBCK01"
"D:\UNIMAINT\UNZIP.EXE" -o SYSBIN01 -d F:\
"D:\UNIMAINT\UNZIP.EXE" -o SYSBDR01 -d F:\
"D:\UNIMAINT\UNZIP.EXE" -o SYSWC01 -d F:\OS2\DLL\
IF EXIST SYSWC01.ZIP ERASE SYSWC01.ZIP
ERASE SYSBIN01.ZIP
ERASE SYSBDR01.ZIP
"F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2.INI"
"F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2SYS.INI"
INICLEAN delete the Desktop directory tree.
If this restore is done to the original system, the result is a
perfect restore. If this restore is done to a new installation, the
restored Desktop will almost always work. However, there will be some
broken references to objects outside the Desktop folder. Most of
these can be fixed.
> Aha, that at least got me somewhere. I used IDebug, which put me
> somewhere into code from PMWP.DLL.
With an exception? If so, I'm willing to look at a process dump.
>Just that I only see assembler
> without any function names, so it doesn't really help.
That's not a problem for me. If you can tell me where pmshell is
loading and what the exception address is, I can find the code.
However, a dump file will probably reveal more.
> No, the first is always FS. And has been in any OS/2 installation as
> far back as I can remember.
I suspect this depends on what you use to display the process type.
It is a PM app, and unless I misread the code it even has a message
loop.
> No, that couldn't find the desktop. Even with the D<path> parameter
> it told me that it couldn't find D<path>. ;-)
I tried this too, just to see what would happen. Unimaint ran OK, but
Checkini refused to run, but for a different reason that you saw.
Peter Weilbacher
> Do you have so many abstract objects that are difficult to
> re-create?
Yes, there were hundreds of program objects, templates, and shadows
that made my life easier.
> When I had a problem like this in the past, I just took it
> on the chin that I was going to lose my intangible objects, but it
> wasn't that big of a loss.
That's what I thought, so I continued to use the desktop setup
provided by the eCS installation and recreated some program
objects when I really needed them. But that never evolved beyond
the basic necessities, probably because this setup was of so
little use to me that I only spent the minimum amount of time on
my home computer.
By now I am a lot more productive on my Linux setup (that I set
up again and customized over the last few months, and also use
at work) than on this basic eCS desktop.
Peter.
Peter Weilbacher
> To restore, the process is reversed.
>
> "D:\UNIMAINT\INICLEAN.EXE" -i"F:\Desktop"
> "F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2.INI"
> "F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2SYS.INI"
> ERASE "F:\OS2\OS2.INI"
> ERASE "F:\OS2\OS2SYS.INI"
> "D:\UNIMAINT\UNZIP.EXE" -j "D:\UNIMAINT\BKUP\SYSBCK01"
> "D:\UNIMAINT\UNZIP.EXE" -o SYSBIN01 -d F:\
> "D:\UNIMAINT\UNZIP.EXE" -o SYSBDR01 -d F:\
> "D:\UNIMAINT\UNZIP.EXE" -o SYSWC01 -d F:\OS2\DLL\
> IF EXIST SYSWC01.ZIP ERASE SYSWC01.ZIP
> ERASE SYSBIN01.ZIP
> ERASE SYSBDR01.ZIP
> "F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2.INI"
> "F:\OS2\ATTRIB.EXE" -R -S -H "F:\OS2\OS2SYS.INI"
>
> INICLEAN delete the Desktop directory tree.
>
> If this restore is done to the original system, the result is a
> perfect restore. If this restore is done to a new installation, the
> restored Desktop will almost always work. However, there will be some
> broken references to objects outside the Desktop folder. Most of
> these can be fixed.
UNIMAINT is in your paths just by chance? Otherwise this is what
I have done for years and again last week: unpack desktop dir and
INIs from ZIP packages. (Well, I don't use WarpCenter so I haven't
restored those files.)
Lars' recipe I only used once that didn't work.
Now that I do have a Desktop that starts and passes checkini I
guess we don't need to discuss this any more (nor the debugging
or process dump option). Just that it is non-functional, in that
it hangs the whole system with any desktop operation, with
SH*EXCEPTIONHANDLER on or off.
I'll try to de-install some classes from the command line to see
if that helps.
Thanks for your (all of you!) help so far!
Peter.
Steven Levine
<news...@weilbacher.org> wrote:
Hi Peter,
> UNIMAINT is in your paths just by chance?
PATH no. LIBPATH yes, although this is probably not really required.
The installer added the LIBPATH entry and I never tried to optimize it
away.
>Otherwise this is what
> I have done for years and again last week: unpack desktop dir and
> INIs from ZIP packages. (Well, I don't use WarpCenter so I haven't
> restored those files.)
OK. Did you delete the existing Desktop tree before the restore?
> Now that I do have a Desktop that starts and passes checkini
Is this a change in behavior or did I misunderstand your previous
explanations? If the behavior did change, what changed it?
>I guess we don't need to discuss this any more (nor the debugging or
>process dump option). Just that it is non-functional, in that
> it hangs the whole system with any desktop operation, with
> SH*EXCEPTIONHANDLER on or off.
Perhaps. A process dump may still be useful. Can you get to a
command line? If so, you can force a process dump and it might be
possible to identify the nature of the hang.
> I'll try to de-install some classes from the command line to see
> if that helps.
That might help. Another debugging option is delete some of the
desktop folders.
Since you can run checkini, if you want to, run
checkini /s /w
and send me a copy of the log. We shall see if I can find anything of
use.
Peter Weilbacher
> On Fri, 13 Nov 2009 09:17:29 UTC, Peter Weilbacher
> <news...@weilbacher.org> wrote:
>
> Hi Peter,
>
>> UNIMAINT is in your paths just by chance?
>
> PATH no. LIBPATH yes, although this is probably not really required.
> The installer added the LIBPATH entry and I never tried to optimize it
> away.
What I meant to ask was really: are those special versions of ZIP
and UNZIP that you use in your script?
>> Otherwise this is what
>> I have done for years and again last week: unpack desktop dir and
>> INIs from ZIP packages. (Well, I don't use WarpCenter so I haven't
>> restored those files.)
>
> OK. Did you delete the existing Desktop tree before the restore?
Yes.
>> Now that I do have a Desktop that starts and passes checkini
>
> Is this a change in behavior or did I misunderstand your previous
> explanations? If the behavior did change, what changed it?
I don't have a good answer. Perhaps activating WatchCat at the right
moment triggered something. In the meantime that worked also for a
second desktop. Maybe it was something else.
What I still find worrying, is that all the time the first instance
of PMSHELL uses 99% CPU. I have never noticed this before. Debugging
that instance isn't possible, right?
>> I guess we don't need to discuss this any more (nor the debugging or
>> process dump option). Just that it is non-functional, in that
>> it hangs the whole system with any desktop operation, with
>> SH*EXCEPTIONHANDLER on or off.
>
> Perhaps. A process dump may still be useful. Can you get to a
> command line? If so, you can force a process dump and it might be
> possible to identify the nature of the hang.
No, it's a hard hang when that happens. Ctrl-Alt-W causes WatchCat
to beep, but that has no effect. Only pressing CAD (twice!) really
does something. (And this system cannot create a _system_ dump.)
>> I'll try to de-install some classes from the command line to see
>> if that helps.
>
> That might help. Another debugging option is delete some of the
> desktop folders.
Will try that, too.
> Since you can run checkini, if you want to, run
>
> checkini /s /w
>
> and send me a copy of the log. We shall see if I can find anything of
> use.
There really isn't anything noteworthy in there. But I'll do that if
I cannot get on otherwise.
Cheers,
Peter.
Dave Yeo
> What I still find worrying, is that all the time the first instance
> of PMSHELL uses 99% CPU. I have never noticed this before. Debugging
> that instance isn't possible, right?
I don't think you can trust the CPU usage reported by WatchCat as it
seems to run a thread at idle to measure. Right now it says Seamonkey is
using 99% but Xcentre reports close to 5% cpu total being used.
Dave
Steven Levine
<news...@weilbacher.org> wrote:
Hi,
> What I meant to ask was really: are those special versions of ZIP
> and UNZIP that you use in your script?
No. Unimaint uses a private copy to make the restore less dependent
on what the user has installed and available in the PATH. Any unzip
that preserves EAs will be fine.
> What I still find worrying, is that all the time the first instance
> of PMSHELL uses 99% CPU. I have never noticed this before. Debugging
> that instance isn't possible, right?
That is odd. This can be debugged. If it were my system, the first
thing I would do is force a process dump of this instance of pmshell.
This is easy and might allow me to discover which thread is
continually busy.
You might be able to run this instance under a full screen debugger
such as sd386 might , but I've not tried this.
The kernel debugger is an option too. Since the system is running
somewhat you might be able to use icat over a network connection.
> No, it's a hard hang when that happens. Ctrl-Alt-W causes WatchCat
> to beep, but that has no effect. Only pressing CAD (twice!) really
> does something. (And this system cannot create a _system_ dump.)
That's not a problem. The system is alive, just not capble of
switching full screen sessions. What I would do is start a full
screen session. Run a script the delays 30 seconds and forces a
process dump. Switch back to the RUNWORKPLACE session and run
pmshell.
> There really isn't anything noteworthy in there. But I'll do that if
> I cannot get on otherwise.
Good luck.
Hendrik Schmieder
>
> On 01/11/09 11:44, Peter Weilbacher wrote:
> Now for the diagnostics:
> - When booting using RUNWORKPLACE=pmshell the system hangs with the
> wait-style mouse pointer at an otherwise black screen. The mouse
> pointer can be moved.
> - I have no idea how in this config I managed to replace the normal
> blue startup screen with black, but as I said, it is the first
> color I see.
> - When activating WatchCat I can see that the PMSHELL.EXE process
> marked FS is taking 99% CPU. None of its properties displayed
> by WatchCat (Threads, DLLs, and Shared Memory) change.
> - I append pstat /c output below that I get when using a command
> line via WatchCat.
> - If I boot with RUNWORKPLACE=cmd I see the same CPU usage of the
> FS pmshell process.
>
> My system is flexible enough for further tests, I hope. And I have
> a backup of the system state before I replaced the old with the new
> computer. The main limitation is my time...
>
Maybe using os2trace with pmshell.exe could give you a hint.
Hendrik