[Vm-dev] Re: LoadLibrary problem on Vista? - supplementary info

Aran Lunzer aran at meme.hokudai.ac.jp
Tue Mar 31 06:19:06 UTC 2009


I trapped the error with DebugDiag, leading to the following output:

-------

Type of Analysis Performed   Crash Analysis
Machine Name                 SUBJUNCTIVITY
Operating System             Windows Vista Service Pack 1
Number Of Processors         2
Process ID                   2088
Process Image                C:\Program Files\C3Squeak\Plugin\C3SqueakVM.exe
System Up-Time               21:30:28
Process Up-Time              00:00:43

Thread 0 - System ID 4276
Entry point                  C3SqueakVM+11d4
Create time                  2009/03/31 13:36:29
Time spent in user mode      0 Days 0:0:2.761
Time spent in kernel mode    0 Days 0:0:9.16

Function                                    Arg 1        Arg 2        Arg
3       Source
ntdll!LdrProcessRelocationBlockLongLong+3e  03b81000     00000001    
03b800f8
ntdll!LdrRelocateImageWithBias+94           03b60000     00000000    
00000000
ntdll!LdrRelocateImage+1d                   03b60000     77b2b1d0    
00000000
ntdll!LdrpMapDll+81a                        01a21308     03b60080    
0022f0c8
ntdll!LdrpLoadDll+249                       00000000     03a21308    
0022f5f0
ntdll!LdrLoadDll+22a                        03a21308     0022f5f0    
0022f5b0
kernel32!LoadLibraryExW+252                 7ffdec00     00000000    
00000000
kernel32!LoadLibraryExA+1f                  0022f650     00000000    
00000000
kernel32!LoadLibraryA+b7                    0022f650     fffffffe    
767a1301
C3SqueakVM+44bf                             005081e0     4000006a    
00000000
C3SqueakVM!primitivePluginRequestState+3eda 00000000     7661b77d    
00000004
gdi32!pbmiConvertInfo+67                    00000000     00000000    
00000000

NTDLL!LDRPROCESSRELOCATIONBLOCKLONGLONG+3EIn
Squeak.exp__PID__2088__Date__03_31_2009__Time_01_37_12PM__639__First
Chance Access Violation.dmp the assembly instruction at
ntdll!LdrProcessRelocationBlockLongLong+3e in
C:\Windows\System32\ntdll.dll has caused an access violation exception
(0xC0000005) when trying to write to memory location 0x03b81014 on thread
0

Module Information
Image Name:     C:\Windows\System32\ntdll.dll   Symbol Type:  PDB
Base address:   0x77ad0000   Time Stamp:  Sat Jan 19 16:32:54 2008
Checksum:       0x00135d86   Comments:
COM DLL: False   Company Name:
ISAPIExtension: False   File Description:
ISAPIFilter: False   File Version:
Managed DLL: False   Internal Name:
VB DLL: False   Legal Copyright:
Loaded Image Name:  ntdll.dll   Legal Trademarks:
Mapped Image Name:     Original filename:
Module name:  ntdll   Private Build:
Single Threaded:  False   Product Name:
Module Size:  1.15 MBytes   Product Version:
Symbol File Name: 
c:\symcache\ntdll.pdb\B958B2F91A5A46B889DAFAB4D140CF252\ntdll.pdb  
Special Build:  &

--------------

I'm not sure what all this tells us.  ntdll.dll is a core part of the
system that's running fine for over a year, so the problem arises in what
ntdll is being asked to do - apparently, to relocate some code into an
unwritable part of memory.  Why would that happen?

Thanks for any help -

Aran


> Hi
>
> I'm having an *intermittent* problem on Vista (not seen on XP - so far)
> when trying to load an external plugin.  Right now I'm seeing it with
> ProcessWrapperPlugin.dll; for the past two weeks - apparently out of the
> blue - I've been seeing what looks like the same problem when accessing
> user32.dll after loading other (.NET bridge) libraries.
>
> This is on a 3.7-based customised Internet Explorer plugin VM, which had
> been working 99% reliably on both XP and Vista for the past 6 months or
> more.
>
> Switching on the VM's debugging, I see that when LoadLibrary fails it does
> so with error 998 ("invalid access to memory location").
>
> Once the problem starts it seems to persist, until the system is rebooted.
>  After reboot it typically works ok for a while.
>
> If the problem I'm seeing here is indeed the same as the one with
> user32.dll (I haven't been able to confirm that yet), it would suggest
> that the loading of an earlier DLL is causing later ones to fail with 998.
>
> Is anyone else seeing this kind of problem, on Vista or elsewhere?
>
> Many thanks -
>
> Aran




More information about the Vm-dev mailing list