Re: Windows Explorer vs CALWIN32.DLL
Alan Adams
> I'm testing out a Windows 7 workstation, connecting to our OES2
> network. I got past the Login Script issues with the Client 2 for
> Windows by deactivating Windows Defender. After a Windows Update every
> time I launched Windows Explorer it crashed and put the fault on
> CALWIN32.DLL. I reinstalled Client 2 and that fixed the problem. I
> then installed MS Office 2003 and was rewarded with the same WinExplorer
> crash, again faulting CALWIN32.DLL. I reinstalled Client 2 again, but
> this time it didn't work. Any tips? Thanks.
Have not heard of that kind of thing being reported for Windows 7
workstations, for what its worth. So I tend to believe that you may
be able to identify some local variable that could avoid or resolve
the situation. (i.e. Not that this is some kind of fundamental or
common Windows 7 issue.)
In general, for a situation of "suddenly the machine starts crashing
in CALWIN32.DLL and re-installing the Novell Client fixes it
temporarily", regardless of which Windows or Novell Client version
we're talking about I would be suspicious that something is replacing
or back-revving either CALWIN32.DLL itself or any of its related
libraries (NETWIN32.DLL, CLNWIN32.DLL, AUDWIN32.DLL, CLXWIN32.DLL,
NCPWIN32.DLL, LOCWIN32.DLL) such that there is a mismatched or
otherwise incompatible set of these DLLs being loaded into memory.
It might be something specific and intentional, such as a ZENworks or
other software distribution action that was appropriately pushing some
files to Windows 5.x workstations. Or it could just be an application
that has older files which didn't cause a problem on Windows 5.x.
When the issue starts occurring, perhaps search to ensure there aren't
multiple copies of these files anywhere on the machine, and also
verify that the one that are there in SYSTEM32 are actually the
versions included in the Novell Client installation set.
You /might/ also look at whether mapped search drives or other Windows
PATH entries might be pointing to a network directory that happens to
have older copies, but that seems an unlikely source of the issue
given that we're talking about EXPLORER.EXE crashing. Which unless
some very non-standard modification of the Windows DLL search order is
in play, will be all but guaranteed to load its instanced of
CALWIN32.DLL and friends from the SYSTEM32 directory.
If none of that pans out, opening a support call with Novell to
provide the dump being generated when EXPLORER.EXE crashes (and/or to
configure Windows to generate a better/bigger dump than it does by
default) would probably be the next most effective step.
Alan Adams
Novell Client CPR Group
alan....@novell.com
Novell
Making IT Work As One
www.novell.com
Upgrade to OES Community
http://www.novell.com/communities/coolsolutions/upgradetooes/
Craig Wilson
--
Craig Wilson - MCNE, MCSE, CCNA
Novell Knowledge Partner
Novell does not officially monitor these forums.
Suggestions/Opinions/Statements made by me are solely my own.
These thoughts may not be shared by either Novell or any rational human.
"GreenNight" <Green...@no-mx.forums.novell.com> wrote in message
news:GreenNig...@no-mx.forums.novell.com...
>
> Did you ever get this fixed? I am experiencing the same issues and may
> open an incident if I don't hear back.
>
>
> --
> GreenNight
> ------------------------------------------------------------------------
> GreenNight's Profile: http://forums.novell.com/member.php?userid=48381
> View this thread: http://forums.novell.com/showthread.php?t=391811
>
craig wilson
Most likely something is backdating or breaking the support DLLs.
On 1/5/2010 5:16 PM, GreenNight wrote:
>
> Yes, there are no other instances of calwin32 on my desktop.
>
>
craig wilson
There is a good chance some install backdated one or more core Windows
files.
On 2/2/2010 1:16 PM, AMCooper63 wrote:
>
> I also have similar Explorer crash issues.
>
> Log Name: Application
> Source: Application Error
> Date: 2/2/2010 10:05:38 AM
> Event ID: 1000
> Task Category: (100)
> Level: Error
> Keywords: Classic
> User: N/A
> Computer: ACooper-PC
> Description:
> Faulting application name: explorer.exe, version: 6.1.7600.16450, time
> stamp: 0x4aebab8d
> Faulting module name: CALWIN32.DLL, version: 6.1.4.0, time stamp:
> 0x4afa6e1f
> Exception code: 0xc0000005
> Fault offset: 0x00000000000021d1
> Faulting process id: 0x1660
> Faulting application start time: 0x01caa42eec6289c5
> Faulting application path: C:\Windows\explorer.exe
> Faulting module path: C:\Windows\system32\CALWIN32.DLL
> Report Id: 90a5efe6-1025-11df-a2fb-00027203bbb6
> Event Xml:
> <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
> <System>
> <Provider Name="Application Error" />
> <EventID Qualifiers="0">1000</EventID>
> <Level>2</Level>
> <Task>100</Task>
> <Keywords>0x80000000000000</Keywords>
> <TimeCreated SystemTime="2010-02-02T18:05:38.000000000Z" />
> <EventRecordID>15955</EventRecordID>
> <Channel>Application</Channel>
> <Computer>ACooper-PC</Computer>
> <Security />
> </System>
> <EventData>
> <Data>explorer.exe</Data>
> <Data>6.1.7600.16450</Data>
> <Data>4aebab8d</Data>
> <Data>CALWIN32.DLL</Data>
> <Data>6.1.4.0</Data>
> <Data>4afa6e1f</Data>
> <Data>c0000005</Data>
> <Data>00000000000021d1</Data>
> <Data>1660</Data>
> <Data>01caa42eec6289c5</Data>
> <Data>C:\Windows\explorer.exe</Data>
> <Data>C:\Windows\system32\CALWIN32.DLL</Data>
> <Data>90a5efe6-1025-11df-a2fb-00027203bbb6</Data>
> </EventData>
> </Event>
>
>
Alan Adams
> So has this been resolved. I understand that there is a "'work
> around" by changing the settings metioned above. But any
> permanent fix?
No, there hasn't been any actual fix or identification of root cause
yet. There has been a difficult time making progress on this issue,
because it simply does not replicate in the labs here. And to date,
no one to whom debug code was provided has been able to successfully
send back results.
If you, or anyone in this thread whom hasn't already been contacted,
are in a position where you can duplicate this problem on a machine
you would be willing to run some rather invasive debug code on, I
invite you to use my email address to contact me and arrange for
having the debug code made available to you. ("Invasive" meaning you
may need to re-install the Novell Client afterwards; might possibly
need to recover the machine by uninstalling from Safe Mode; etc.)
Note the workaround of replacing CALWIN32.DLL with a pre-Novell Client
4.91 SP3 build of CALWIN32.DLL does "make sense" for why it affects
the problem, because dumps of crashed EXPLORER.EXE and other processes
show the issue is occurring in a Windows 6.x-specific section of code
related to SLP name resolution.
The older CALWIN32.DLL simply lacks this Windows 6.x-specific code
entirely, and therefore would avoid the crash; but the older
CALWIN32.DLL will also be unable to employ SLP name resolution on
Windows 6.x platforms, which can prevent things like the tree browse
and network view from being populated.
Its unknown in what way the workaround of changing the icon/details
view in Windows Explorer affects the problem; the information being
requested of the Novell Client is the same in both configurations, so
its unclear how this is indirectly having an affect on the root cause.