[Vm-dev] Re: LoadLibrary problem on Vista? - supplementary info
Andreas Raab
andreas.raab at gmx.de
Tue Mar 31 06:38:37 UTC 2009
I have no clue. This is the first time I've ever heard of something like
it. However, it looks like this is a custom VM, no? If it is, I would
recommend running one of the release VMs instead to see if you get the
same problem or not. If you don't, then I think it's safe to assume that
the problem is related to whatever modifications you've been doing.
Cheers,
- Andreas
Aran Lunzer wrote:
>
> 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