nwlscrpt.exe - Application Error
shaun_dark_lord
Am getting the following error message on a new workstation when a
normal user logs in;
http://www.blackfen.bexley.sch.uk/temp/nwlscrpt.jpg
> Dummy Window: nwlscrpt.exe - Application Error
> The instrauction at "0x6c379d64" referenced memory at "0x00000809". The
> memory could not be "read".
We had this issue about six months ago - At the time we applied the fix
reccomended in 'TID 10096109' (http://tinyurl.com/m7pw8), which fixed
the problem. Since then, we have not had to apply the fix, as Windows
2000 Update Rollup 1 seemed to fix the problem.
But now we have a new PC having the same issue - I've tried the Hotfix
and reinstalling the Rollup - neither make any difference.
--
shaun_dark_lord
Shaun
Alan Adams
> Dummy Window: nwlscrpt.exe - Application Error
> The instrauction at "0x6c379d64" referenced memory at "0x00000809". The
> memory could not be "read".
That address (0x6c379d64) suggests the crash occurred related to an
MFC42.DLL call that was going on. Which would mean whatever the root
cause is, in the case you're looking at, is indeed different than the
root cause of TID 10096109 (which was clearly in NTDLL.DLL).
One thing that does bring to mind is TID 10090679, where NWLSCRPT.EXE
was crashing. You haven't yet cited which version of the Novell
Client you're running, so I can't tell if this should already be ruled
out or not.
TID10090679 - Windows Explorer will not load
http://support.novell.com/docs/Tids/Solutions/10090679.html
If that doesn't seem like it should apply to your case, perhaps just
generically search this new computer's entire hard drive for multiple
copies of LOGINW32.DLL and/or MFC42.DLL, in case there is some older
version lurking in a location that could potentially become loaded
into memory.
Alan Adams
alancru...@drcrumb.com
(for email, remove the crumbs)
craig wilson
This will show all of the DLLs that MFC42.DLL and Login32.DLL may call.
Alan would know better, but I would presume that an old DLL that
MFC42.dll used could be an issue as well.
> If that doesn't seem like it should apply to your case, perhaps just
> generically search this new computer's entire hard drive for multiple
> copies of LOGINW32.DLL and/or MFC42.DLL, in case there is some older
> version lurking in a location that could potentially become loaded
> into memory.
--
Craig Wilson
Novell Product Support Forum Sysop
Master CNE, MCSE 2003, CCN
Alan Adams
> I'm running Client 4.91 SP2
>
> I've just done a fresh install of everything, and am getting the same
> problem again.
Hit "Cancel" on the error so that hopefully DRWTSN32.EXE will be
invoked and will write a dump and log of the crash. (Run DRWTSN32.EXE
without parameters to see where its configured to write the log and
dump.)
If you can de-obfuscate my email address and email me a link to a
location you can make the .DMP available, I'd be happy to confirm
which MFC42, LOGINW32 and such are being loaded and if there is
anything more about the issue that seems apparent.
If you don't have a place to make it available for download, you can
try .ZIPing it and emailing that, but I can't guarantee it will fit
through my inbox.
Either way, you would want to hold on to a dump like that of the
issue, in case push eventually comes to shove and you have to open a
support incident with Novell. Having that dump would be the most
definitive thing to provide in showing what the issue is.
shaun_dark_lord
I'm running Client 4.91 SP2
I've just done a fresh install of everything, and am getting the same
problem again.
--
shaun_dark_lord
Shaun
shaun_dark_lord
I'll do that first thing on Monday
Thanks - Have a good weekend.
--
shaun_dark_lord
Shaun
MikeH
Alan,
here is a link to the dump file... if you could have a look at it, it
would be much appreciated :)
http://www.blackfen.bexley.sch.uk/temp/user.dmp
cheers
Mike
--
MikeH
Alan Adams
> here is a link to the dump file... if you could have a look at it, it
> would be much appreciated :)
>
> http://www.blackfen.bexley.sch.uk/temp/user.dmp
Downloaded successfully; you can take it down.
The crash is about five levels down inside MFC42.DLL
(MFC42!COleControlSite::QuickActivate) from a
MFC42!CWnd::CreateControl call initiated from LOGINW32.DLL.
At least based on the public MFC42.DLL source code, the issue is not
clearly related to how LOGINW32.DLL has invoked MFC. i.e. Can't
clearly point to something indicating "and here is where Novell's code
went wrong in causing this".
(The MFC code in question appears to be trying to "inherit" font
information from the containing/parent window, and one of the calls to
obtain this information apparently failed. But MFC doesn't
error-check the call, as though its never expected to fail, and chaos
ensues. Why the font information couldn't be queried is probably more
the question/issue though.)
Nothing appears obviously amiss to me in the modules that had become
loaded on NWLSCRPT.EXE with regard to LOGINW32.DLL, LGNWNT32.DLL,
MFC32.DLL, OLE32.DLL, OLEAUT32.DLL, and everything else present on the
NWLSCRPT.EXE process at the time of the crash.
One thing from the dump that is more of a "long shot" was that I
noticed NetIdentity was installed. Try just renaming
"C:\WINNT\system32\Novell\XtExtend.dll" to "XtExtend.disabled.dll" and
then reboot and confirm the issue still happens even with NetIdentity
out of the NWLSCRPT.EXE process.
But nothing jumped out as more clearly identified or suspicious from
the dump. Since you said you've already done a clean re-installation
of "everything", it sounds like you're either going to have to spend
more time with a brute-force elimination/inclusion of factors (e.g. it
doesn't happen after installing 4.91 SP2 alone; it still doesn't
happen after adding ZENworks agent to that mix; etc.) or else open a
support issue.
I do think it would probably take someone from Microsoft looking at
the dump to truly analyze what has gone wrong from MFC's perspective.
(Or at least "analyzing it quickly".) But you should be able to take
the issue to whomever you have the better support arrangement with
(Microsoft for the crash being in MFC, or Novell for it being on
NWLSCRPT) and then let Microsoft and Novell work out together who
needs to look at what.
MikeH
Alan,
Thanks very much for that detailed responce, much appreciated ... I
will try renaming the XtExtend.dll and see what happens
cheers
Mike
--
MikeH
MikeH
MikeH Wrote:
> Alan,
>
> Thanks very much for that detailed response, much appreciated ... I
> will try renaming the XtExtend.dll and see what happens
>
> cheers
>
> Mike
no joy with that .... still comes up with error message and hangs
--
MikeH
MikeH
Tommy Mikkelsen Wrote:
>
> > The MFC code in question appears to be trying to "inherit" font
> > information from the containing/parent window
>
> of the wkstn, or the driver used ????
>
> --
> Best Regards
>
> Tommy Mikkelsen
>
> IT Quality A/S
> Denmark
>
> Novell Support Forums SYSOP
>
> Please Report back any success or failure, That way we all learn
>
> Sorry, but no support through email
>
> "I hate bugs".......Tommy Lee Jones, MIB
>
> Be a GroupWiseR, go http://www.groupwiser.net
the workstation is using the latest NVidia Drivers for a Geforce 7300LE
.... I will have a play with the driver and see if anything changes
--
MikeH
Tommy Mikkelsen
> The MFC code in question appears to be trying to "inherit" font
Alan Adams
> > The MFC code in question appears to be trying to "inherit" font
> > information from the containing/parent window
>
> Couldn't this be related to the grapich settings (Resolution or color)
> of the wkstn, or the driver used ????
This code appears to be executing "all the time" from what I can tell.
i.e. The manner in which LOGINW32.DLL and MFC42.DLL interact on this
point is occurring not only when NWLSCRPT.EXE runs, but also when
LOGINW32.DLL and MFC42.DLL are used to present the initial login
dialog from GINA, and/or when running LOGINW32.EXE from the desktop.
If its failing due to something fundamental like the video driver /
system configuration, its very subtle that the initial login dialog
doesn't fail in the same way.
Tommy Mikkelsen
Alan Adams
> Worth a shut though, or ???
MikeH is already following up on that point. I'm being nitpicky, and
not even necessarily 100% correct, in thinking that "fonts" are a
Windows concept, and not a video driver concept. They're just
rendered through the video driver; not defined or selected by.
But this is all through the lens of my gross ignorance of what MFC is
actually doing. It just "looks" to me like they're trying to read
what font is selected in the container in order to propagate that to
the child being created.
All angles are worth following up on if possible. Finding out that
Standard VGA works fine might not be helpful, but finding out that an
older high-functioning driver works could provide at least a
workaround without identifying the cause.
MikeH
It seems as though it is a permissions problem with one of the dlls
with c:\winnt\system32 ... as a quick test we reapplied the inheritable
permissions to all files within the c:\winnt\system32 (some files had
the inheritable permissions removed, mfc42.dll, ole32.dll and
ole32auth.dll) and then logged into the workstations without receiving
the nwlscrpt.exe error message ... we will try and narrow down which
dll(s) cause the problem now and post back with further results
..we tried checking the iheritable permissions first on the following
files
mfc42.dll
ole32.dll
ole32auth.dll
LOGINW32.DLL
LGNWNT32.DL
NWLSCRPT.EXE
XtExtend.dll
..
but still received the error message
--
MikeH
Alan Adams
> It seems as though it is a permissions problem with one of the dlls
> with c:\winnt\system32 ... as a quick test we reapplied the inheritable
> permissions to all files within the c:\winnt\system32 (some files had
> the inheritable permissions removed, mfc42.dll, ole32.dll and
> ole32auth.dll) and then logged into the workstations without receiving
> the nwlscrpt.exe error message ... we will try and narrow down which
> dll(s) cause the problem now and post back with further results
Interesting. Permissions does at least fit with the "only happens on
NWLSCRPT" (and not on the initial boot login dialog) since NWLSCRPT is
running as the user as opposed to the initial login dialog which would
be running as LocalSystem.
(But it may also imply that running LOGINW32.EXE from the user's
desktop might also show the same crash?)
If you did find that running LOGINW32.EXE produces a similar crash,
that could at least be an easier test as you determine what
permissions seem to be at issue.
(Plus could make it much easier to use tools like Sysinternals'
FileMon to watch which file operations are succeeding versus failing
in the success versus non-success scenarios.)