LoadLibrary problem on Vista?
Locked
 
|
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 |
Re: LoadLibrary problem on Vista? - supplementary info
|
|
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 |
Re: Re: LoadLibrary problem on Vista? - supplementary info
|
|
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 > > |
Re: LoadLibrary problem on Vista? - supplementary info
|
|
In reply to this post by Aran Lunzer
Andreas wrote: > 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. Fair point. I've now confirmed that the problem occurs with VMs as supplied with 3.9 (Sept 2004) and 3.10 (Aug 2007). The reason for this problem being intermittent seems to be that it depends on what DLLs you've loaded, and whether any of them happens to be occupying the address space normally used for the DLL you want to load now. It seems like something of a lottery. But perhaps the fact that I'm normally running inside Internet Explorer, and loading a bunch of other DLLs, makes such clashes more likely? Otherwise it's odd that no-one else is seeing this. Meanwhile, Korakurider pointed me to the following information about DLL-relocation problems with gcc: >By quick googling I found >http://oakham.cs.ucl.ac.uk/pipermail/sumover-dev/2009-January/000982.html >that shows similar symptom and (possible) root cause. > >> "The problem is that DLLs generated by MingW GCC (with -shared) are not > > correctly relocatable, even though they contain relocation information. > > LoadLibrary() returns ERROR_NOACCESS if it is forced to relocate the DLL > > and a backtrace shows a blind jump into bad memory from > > __gcc_register_frame. " So it looks like there is some precedent for this kind of problem - though I can't tell whether our situation quite matches this one. For a start, they are talking about a later release of gcc. Anyway, I've now managed to install the ProcessWrapper plugin source and build my own dll. The problem remains as before, which wouldn't be surprising if my build environment is basically the same as for the distributed version. The question is (I guess) whether I can now flick some switch to create a version that doesn't barf when relocated. (One thing I notice is that the new DLL is larger than the distributed one: 121344 bytes cf 115712. Presumably some difference in the C or CXX flags? For the record, mine are as seen here: gcc -c -g3 -O3 -mpentium -mwindows -fomit-frame-pointer -funroll-loops -fschedule-insns2 -I. -I../.. -I../../vm -Ic:/dx7sdk/include -DLSB_FIRST -DX86 ProcessWrapperPlugin.c g++.exe -c main.cpp -o main.o -g3 -O3 -mpentium -mwindows -fomit-frame-pointer -funroll-loops -fschedule-insns2 -I. -I../.. -I../../vm -Ic:/dx7sdk/include -felide-constructors ) Ok, so... it seems that Squeak VM-building tools are based on gcc 2.95. If the relocation problem is related to gcc, and if it was fixed in a later release, is it a simple matter for me to install that instead? Presumably I wouldn't need to use the new compiler for the VM, but just the external DLLs. Thanks - Aran |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |