Unexplained VM crash

Guys,

On one specific customer machine our VisualSmalltalk applications refuses to start – you get an immediate non-continuable protection violation the second the application launches (and before it has a chance to start dynamically binding any of the SLLs that contain the application code).

There are usually two things that produce this symptom. The first is if the machine in question has DEP switched on and the application isn’t listed as an exception; the second is if there’s some DLL or device driver occupying an absolute memory address which conflicts with the range of addresses the VM requests when it launches. However, in this case, we’ve checked that DEP is not the problem; and although the standard version of the application requests a 700MB range of addresses at launch, we’ve tried substituting an image .exe which requests only the 100MB default range – and that crashes too.

It could be that there’s an absolute memory blockage even in  the 100MB range, I suppose, but I wondered if anyone had any other suggestions for something else might cause this kind of VM crash.

We’re still using VSW version 3.1.2d. In case it’s any help, the register values from the error.log are as follows:

The registers were:

EIP = 0x00b8020d

ESP = 0x0012fee0

EBP =  0x00000000

EAX = 0x00df4444

EBX = 0xffffe001

ECX = 0x7c8285ec

EDX = 0x00000001

ESI = 0x00df4444

CS = 0x0000001b

DS = 0x00000023

ES = 0x00000023

SS = 0x00000023

End Registers

A particularly odd aspect of this is that the application used to run on that box successfully. Our implementation guy reckons that the failures started after .NET 4.0 was installed on the machine – but other  machines with .NET 4.0 installed seem to be unaffected.

Any suggestions?

Rgds,

Nicolas.

Can you check at what address the VM is loaded? Usually it loads at 0x10000000. But the error you get is in 0x00B8020D. Is this due to the VM being loaded at that address, or is it due to execution of JIT compiled code or execution in some 3^rd module?

May be the error happens only when the VM cannot be loaded at 0x10000000. Check the modules list in the debugger.

Guys,

On one specific customer machine our VisualSmalltalk applications refuses to start – you get an immediate non-continuable protection violation the second the application launches (and before it has a chance to start dynamically binding any of the SLLs that contain the application code).

There are usually two things that produce this symptom. The first is if the machine in question has DEP switched on and the application isn’t listed as an exception; the second is if there’s some DLL or device driver occupying an absolute memory address which conflicts with the range of addresses the VM requests when it launches. However, in this case, we’ve checked that DEP is not the problem; and although the standard version of the application requests a 700MB range of addresses at launch, we’ve tried substituting an image .exe which requests only the 100MB default range – and that crashes too.

It could be that there’s an absolute memory blockage even in  the 100MB range, I suppose, but I wondered if anyone had any other suggestions for something else might cause this kind of VM crash.

We’re still using VSW version 3.1.2d. In case it’s any help, the register values from the error.log are as follows:

The registers were:

EIP = 0x00b8020d

ESP = 0x0012fee0

EBP =  0x00000000

EAX = 0x00df4444

EBX = 0xffffe001

ECX = 0x7c8285ec

EDX = 0x00000001

ESI = 0x00df4444

CS = 0x0000001b

DS = 0x00000023

ES = 0x00000023

SS = 0x00000023

End Registers

A particularly odd aspect of this is that the application used to run on that box successfully. Our implementation guy reckons that the failures started after .NET 4.0 was installed on the machine – but other  machines with .NET 4.0 installed seem to be unaffected.

Any suggestions?

Rgds,

Nicolas.

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Can you check at what address the VM is loaded? Usually it loads at 0x10000000. But the error you get is in 0x00B8020D. Is this due to the VM being loaded at that address, or is it due to execution of JIT compiled code or execution in some 3^rd module?

May be the error happens only when the VM cannot be loaded at 0x10000000. Check the modules list in the debugger.

Guys,

On one specific customer machine our VisualSmalltalk applications refuses to start – you get an immediate non-continuable protection violation the second the application launches (and before it has a chance to start dynamically binding any of the SLLs that contain the application code).

There are usually two things that produce this symptom. The first is if the machine in question has DEP switched on and the application isn’t listed as an exception; the second is if there’s some DLL or device driver occupying an absolute memory address which conflicts with the range of addresses the VM requests when it launches. However, in this case, we’ve checked that DEP is not the problem; and although the standard version of the application requests a 700MB range of addresses at launch, we’ve tried substituting an image .exe which requests only the 100MB default range – and that crashes too.

It could be that there’s an absolute memory blockage even in  the 100MB range, I suppose, but I wondered if anyone had any other suggestions for something else might cause this kind of VM crash.

We’re still using VSW version 3.1.2d. In case it’s any help, the register values from the error.log are as follows:

The registers were:

EIP = 0x00b8020d

ESP = 0x0012fee0

EBP =  0x00000000

EAX = 0x00df4444

EBX = 0xffffe001

ECX = 0x7c8285ec

EDX = 0x00000001

ESI = 0x00df4444

CS = 0x0000001b

DS = 0x00000023

ES = 0x00000023

SS = 0x00000023

End Registers

A particularly odd aspect of this is that the application used to run on that box successfully. Our implementation guy reckons that the failures started after .NET 4.0 was installed on the machine – but other  machines with .NET 4.0 installed seem to be unaffected.

Any suggestions?

Rgds,

Nicolas.

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

If you don’t have it already, download “Debugging Tools for Windows” (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) and install it.

Run “WinDbg”, the 32bit version and attach to the VSE process.

At the command prompt, run the “lm” command (list modules).

I don’t have VSE myself, but here’s an example for a random process:

lm

start    end        module name

011e0000 0121a000   FlashUtil10k_ActiveX   (deferred)            

6cae0000 6cb2d000   FlashUtil10k_ActiveX_6cae0000   (deferred)             

6cb30000 6cb7d000   DFB4       (deferred)            

73300000 73380000   uxtheme    (deferred)            

737d0000 737de000   RpcRtRemote   (deferred)            

...

You have the module name, start and end address. Find the module (if any), where the value of EIP register is between start and end addresses. Be aware that those are not constant and may change every time the process is restarted.

Can you check at what address the VM is loaded? Usually it loads at 0x10000000. But the error you get is in 0x00B8020D. Is this due to the VM being loaded at that address, or is it due to execution of JIT compiled code or execution in some 3^rd module?

May be the error happens only when the VM cannot be loaded at 0x10000000. Check the modules list in the debugger.

Guys,

On one specific customer machine our VisualSmalltalk applications refuses to start – you get an immediate non-continuable protection violation the second the application launches (and before it has a chance to start dynamically binding any of the SLLs that contain the application code).

There are usually two things that produce this symptom. The first is if the machine in question has DEP switched on and the application isn’t listed as an exception; the second is if there’s some DLL or device driver occupying an absolute memory address which conflicts with the range of addresses the VM requests when it launches. However, in this case, we’ve checked that DEP is not the problem; and although the standard version of the application requests a 700MB range of addresses at launch, we’ve tried substituting an image .exe which requests only the 100MB default range – and that crashes too.

It could be that there’s an absolute memory blockage even in  the 100MB range, I suppose, but I wondered if anyone had any other suggestions for something else might cause this kind of VM crash.

We’re still using VSW version 3.1.2d. In case it’s any help, the register values from the error.log are as follows:

The registers were:

EIP = 0x00b8020d

ESP = 0x0012fee0

EBP =  0x00000000

EAX = 0x00df4444

EBX = 0xffffe001

ECX = 0x7c8285ec

EDX = 0x00000001

ESI = 0x00df4444

CS = 0x0000001b

DS = 0x00000023

ES = 0x00000023

SS = 0x00000023

End Registers

A particularly odd aspect of this is that the application used to run on that box successfully. Our implementation guy reckons that the failures started after .NET 4.0 was installed on the machine – but other  machines with .NET 4.0 installed seem to be unaffected.

Any suggestions?

Rgds,

Nicolas.

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Am I wrong in my assessment that VSE’s PrintDialog class only copies its PRINTDLG structure to non Smalltalk memory but then does not do anything to read it back once the dialog window has been dismissed?  It implements methods to fetch the devMode and devNames structs from memory, but not the printDlg struct.

This is a bit problematic for those of us who want to know how many copies to print, or get a page range, etc.

-Carl Gundel

Psyche Systems Corp.

http://www.psychesystems.com

Hi Carl,

not sure what version you use,

but I find method PrintDialog>>checkFlags, which is invoked after the dialog is closed, and copies back some properties of the struct, among others the ‘copies’ you mention.

Manfred

Am I wrong in my assessment that VSE’s PrintDialog class only copies its PRINTDLG structure to non Smalltalk memory but then does not do anything to read it back once the dialog window has been dismissed?  It implements methods to fetch the devMode and devNames structs from memory, but not the printDlg struct.

This is a bit problematic for those of us who want to know how many copies to print, or get a page range, etc.

-Carl Gundel

Psyche Systems Corp.

http://www.psychesystems.com

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***

Hi Carl,

We have a number of changes to the print dialog class.

I’ll send you the source offline.

-- Derek

Am I wrong in my assessment that VSE’s PrintDialog class only copies its PRINTDLG structure to non Smalltalk memory but then does not do anything to read it back once the dialog window has been dismissed?  It implements methods to fetch the devMode and devNames structs from memory, but not the printDlg struct.

This is a bit problematic for those of us who want to know how many copies to print, or get a page range, etc.

-Carl Gundel

Psyche Systems Corp.

http://www.psychesystems.com

*** this signature added by listserv *** *** Visit http://www.listserv.dfn.de/archives/vswe-l.html *** *** for archive browsing and VSWE-L membership management ***