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