Quantcast

[VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Peter Uhnak
Hi,

recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Debug console
# To close: F2 -> 'debug options' -> 'show output console'
# To disable: F2 -> 'debug options' -> 'show console on errors'
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.

)
LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.

)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb  3 2017 (downloaded from files.pharo.org)

This error results in Athens (and Roassal) not working, although Pharo itself seems fine.

Reopening the image has no effect, and the only resolution is to do a system reboot.


There is also crash.dmp from Feb 12 (possibly the day it started) containing

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sun Feb 12 23:10:24 2017

Exception code: C0000005
Exception addr: 0040BDD0
Access violation (write access) at 00AFF43C
EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C
ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54
EIP:0040BDD0 EFL:00010206
FP Control: 0000027F
FP Status:  00000000
FP Tag:     0000FFFF


Crashed in some other thread
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it.

Thanks,
Peter

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

CyrilFerlicot
On 16/02/2017 11:06, Peter Uhnak wrote:

> Hi,
>
> recently (couple of days ago) sometimes when I start Pharo there's a box at the bottom "Debug console" with the following info
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> # Debug console
> # To close: F2 -> 'debug options' -> 'show output console'
> # To disable: F2 -> 'debug options' -> 'show console on errors'
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin) (998: Invalid access to memory location.
>
> )
> LoadLibrary(SurfacePlugin.dll) (998: Invalid access to memory location.
>
> )
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I have Windows 10 & VM Version: Cog Spur VM 5.0 (release) from Feb  3 2017 (downloaded from files.pharo.org)
>
> This error results in Athens (and Roassal) not working, although Pharo itself seems fine.
>
> Reopening the image has no effect, and the only resolution is to do a system reboot.
>
>
> There is also crash.dmp from Feb 12 (possibly the day it started) containing
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Sun Feb 12 23:10:24 2017
>
> Exception code: C0000005
> Exception addr: 0040BDD0
> Access violation (write access) at 00AFF43C
> EAX:FFFFFFFF EBX:74329850 ECX:549D7EBE EDX:00AFF43C
> ESI:74315F70 EDI:00489DB9 EBP:0887FF94 ESP:0887FF54
> EIP:0040BDD0 EFL:00010206
> FP Control: 0000027F
> FP Status:  00000000
> FP Tag:     0000FFFF
>
>
> Crashed in some other thread
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Makes me wonder whether the SurfacePlugin.dll didn't somehow get corrupted... but then again there's no modification date change on the dll file, nor would it explain why rebooting fixes it.
>
> Thanks,
> Peter
>
Hi,

I got the same problem with the latest vm some weeks ago on Windows 7.
It vanished by downloading a new vm some days after.

I did not try with the current latest. I'll maybe have the time to try
this week end.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


signature.asc (817 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Peter Uhnak
On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
>
> I got the same problem with the latest vm some weeks ago on Windows 7.
> It vanished by downloading a new vm some days after.

I've downloaded the latest VM and it works as expected. Thanks!

Peter

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Peter Uhnak
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

tinchodias
Same here, in #60442.

Smalltalk vm version --->
"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $
'"

cmd ver --->
Microsoft Windows [Versión 10.0.14393]



Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new 
        package: 'ConfigurationOfRoassal2';
        load.
#ConfigurationOfRoassal2 asClass load.



Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Peter Uhnak
I still do see it ocassionally too... sometimes corelated to dual-booting and network interface fuckery (by that I mean that Windows doesn't detect network, or even wireless perhiperhals like mouse... but Windows 10 yay...)

for the load time... sometime firewall/AV can fuck it up... but generally it should be always slower than linux, because Windows can't files.

(I am using the latest VM usually)

Peter

On Thu, Mar 16, 2017 at 01:11:03AM -0300, Martin Dias wrote:

> Same here, in #60442.
>
> Smalltalk vm version --->
> "'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
> StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid:
> 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
> VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed
> Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539
> https://github.com/pharo-project/pharo-vm.git $
> '"
>
> cmd ver --->
> Microsoft Windows [Versión 10.0.14393]
>
>
>
> Additionally:
>
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux
> (same notebook). Script:
>
> Gofer new
>         url: 'http://www.smalltalkhub.com/mc/ObjectProfile/Roassal2/main';
>         package: 'ConfigurationOfRoassal2';
>         load.
> #ConfigurationOfRoassal2 asClass load.
>
>
>
> Martin
>
> On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
>
> > Well, I take that back.
> >
> > Today I had the same issue (with the latest VM).
> > Closing the image and reopening it helped, but clearly there is something
> > broken underneath.
> >
> > Peter
> >
> > On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> > > On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> > > >
> > > > I got the same problem with the latest vm some weeks ago on Windows 7.
> > > > It vanished by downloading a new vm some days after.
> > >
> > > I've downloaded the latest VM and it works as expected. Thanks!
> > >
> > > Peter
> >
> >

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

Eliot Miranda-2
In reply to this post by tinchodias
Hi Martin,

    hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results.  Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive.  But in any case, some kind of profiling would point to why things are so much slower on Windows.

On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <[hidden email]> wrote:
Same here, in #60442.

Smalltalk vm version --->
"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $
'"

cmd ver --->
Microsoft Windows [Versión 10.0.14393]



Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new 
        package: 'ConfigurationOfRoassal2';
        load.
#ConfigurationOfRoassal2 asClass load.



Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter





--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

CyrilFerlicot
In reply to this post by tinchodias
Le 16/03/2017 à 05:11, Martin Dias a écrit :
> And it takes >30 minutes to load Roassal2, while takes <1 minyte in
> Linux (same notebook). Script:
>

Do you have an anti-virus? If yes did you excluded the .changes and ombu
files from the files to check? If not the anti-virus might analyze your
file at each compilation.

--
Cyril Ferlicot

http://www.synectique.eu

2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [VM] Windows VM SurfacePlugin.dll LoadLibrary failure

philippeback
In reply to this post by Eliot Miranda-2
How does one use the VMProfiler?

Phil

On Thu, Mar 16, 2017 at 9:01 PM, Eliot Miranda <[hidden email]> wrote:
Hi Martin,

    hopefully the VMProfiler still runs on Windows so you could use it to profile the VM as it loads Rossal2 and I can help you decode the results.  Alternatively you could use AndreasSystemProfiler and see which primitives are particularly expensive.  But in any case, some kind of profiling would point to why things are so much slower on Windows.

On Wed, Mar 15, 2017 at 9:11 PM, Martin Dias <[hidden email]> wrote:
Same here, in #60442.

Smalltalk vm version --->
"'CoInterpreter * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
StackToRegisterMappingCogit * VMMaker.oscog-EstebanLorenzano.2136 uuid: 40534c32-ca6b-4e97-91ec-31d509e49b0c Feb 22 2017
VM: 201702221539 https://github.com/pharo-project/pharo-vm.git $ Date: Wed Feb 22 16:39:40 2017 +0100 $ Plugins: 201702221539 https://github.com/pharo-project/pharo-vm.git $
'"

cmd ver --->
Microsoft Windows [Versión 10.0.14393]



Additionally:

And it takes >30 minutes to load Roassal2, while takes <1 minyte in Linux (same notebook). Script:

Gofer new 
        package: 'ConfigurationOfRoassal2';
        load.
#ConfigurationOfRoassal2 asClass load.



Martin

On Fri, Feb 24, 2017 at 8:52 AM, Peter Uhnak <[hidden email]> wrote:
Well, I take that back.

Today I had the same issue (with the latest VM).
Closing the image and reopening it helped, but clearly there is something broken underneath.

Peter

On Wed, Feb 22, 2017 at 09:29:12PM +0100, Peter Uhnak wrote:
> On Thu, Feb 16, 2017 at 12:19:00PM +0100, Cyril Ferlicot D. wrote:
> >
> > I got the same problem with the latest vm some weeks ago on Windows 7.
> > It vanished by downloading a new vm some days after.
>
> I've downloaded the latest VM and it works as expected. Thanks!
>
> Peter





--
_,,,^..^,,,_
best, Eliot

Loading...