Bill, off-hand I don't know why those mutex-related messages came up. If
those can be reliably reproduced, then a call to technical support might
be in order (sorry, but there are a lot of unknowns that prevent an "aha,
here is your problem" kind of answer). But I don't see how those messages
would trigger a blue screen, and in fact, their presence with the
blue-screen could merely be coincidental. That is, maybe there are two
separate issues at work that just happened to come up at the same time.
Again, if you want to pursue the cause (which I think is a good idea),
your best bet is to analyze the memory.dmp file that was (hopefully)
captured to find the failing module, and go on from there. In fact,
further diagnosis of the blue screen is not possible without that
analysis, since you otherwise have no idea what module crashed. Proper
diagnosis has to start with the failing module, and the dump presented to
the owner of that module, so they can figure out what triggered the kernel
exception.
Notes: If this was an upgrade of an existing TSM installation, then unless
care was taken to stop all running instances of the client executables, a
reboot would be required to complete the install. If the reboot was not
done, then the client installation would be unstable until the reboot. If
online image or OFS support was enabled, a reboot would likewise need to
have been done.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-08-25
12:04:34:
> In the dsmerror.log file these messages came up when I was
> installing the services with dsmcutil.exe. The services installed and
are
> functioning, but during installation the message came up that it
> failed to validate the password with the TSM server.
>
> 08/24/2005 13:11:13 Mutex lock failed: 6.
> 08/24/2005 13:11:13 Release mutex failed; reason 6.
> 08/24/2005 13:11:13 Mutex lock failed: 6.
> 08/24/2005 13:11:13 Release mutex failed; reason 6.
> 08/24/2005 13:11:16 Mutex lock failed: 6.
> 08/24/2005 13:11:16 Release mutex failed; reason 6.
>
>
>
>
> Bill Boyer
> "Some days you're the bug, some days you're the windshield" - ??
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On
> Behalf Of Andrew Raibeck
> Sent: Thursday, August 25, 2005 6:37 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Anyone seen TDP Domino blue screen a Windows2000 server??
>
> Bill, off-hand the only TSM client component could (hypothetically)
> cause of a blue-screen would be the LVSA module, tsmlvsa.sys.
> When you installed the backup-archive client, did you configure it
> to use online image backup or open file support?
>
> Otherwise I can't think of anything that TSM could do to cause a
> blue-screen. Application crash?... yes... but blue screen?... no.
>
> Having said that... was a memory.dmp file captured? If so, I'd
> recommend using the Windows debugger to analyze it as the first step.
> Usually memory.dmp is located in %SystemRoot% (C:\WINNT or C:
> \WINDOWS). The latest version of the debugger can be obtained from
> Microsoft at:
>
> http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx
>
> download the debugging tools from the above address and install
> them. The default install location is "c:\Program Files\Debugging
> Tools for Windows". Add the directory where the debugging tools were
> installed to your PATH environment variable, then run the
> console debugger as follows from an OS prompt:
>
> set
> _NT_SYMBOL_PATH=srv*c:\symbols*http://msdl.microsoft.
> com/download/symbols;%SystemRoot%\system32
>
> cdb -z c:\winnt\memory.dmp -c "!analyze -v;v"
>
> (This assumes that the memory.dmp file is located in c:\winnt.)
>
> The "set" command will tell the debugger where it can find Windows
> symbol files.
>
> The console debugger output should indicate (among other things) the
> module that caused the kernel exception. Then follow up with
> the owner of that module for additional analysis.
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development Internal Notes e-mail:
> Andrew Raibeck/Tucson/IBM@IBMUS Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2005-08-24
> 17:55:00:
>
> > I was at a client site today doing a TSM implementation and we
> > installed the TSM 5.3.0.8 client followed by the 5.3 TDP Domino agent.
> > Running the domdsmc I was able to changeadsmpwd, query adsm, query
> > domino and actually do some selective backups. I then went into the
> > DSMC client and ran a QUERY SESSION. I then installed the CAD, RCA and
> > scheduler services. What was strange on that was that the dsmcutil
> > installed the services but failed to validate the password. Looking
> > int he dsmerror.log file I saw some error messages about Mutex
> > something-or-other. The services were working as I ran a client action
> > on the node.
> >
> > When I tried to do a backup using the TDP DOmino GUI, I selected a
> > couple files and clicked backup. The dialog came up, but never
> > started. I never got a session with the TSM server and the Stop button
> > wouldn't function.
> >
> > I then went into the web gui, clicked backup and after replying to the
> > password prompt, the box blue screened with a
> > kmode_kernal_mode_exception. These people were not happy. Blaming TSM.
> >
> > In over 7-years working with the product I have never seen the client
> > take down a server like that. Anyone actually seen something like
> > this??
> >
> > Bill Boyer
> > "Growing old is mandatory, growing up is optional" - ??
|
