We have some code that use windows that we created in App Builder to allow users to enter variables. Since moving to V11.02 of OpenEdge any code that uses a window from a .w file is crashing Openedge. (they just bomb out with the ‘Windows Graphical Client Not Responding’ message). However the code compiles fine - there has been no changes to the code at all. Are we missing something here that has changed since moving from V10 to V11 - can someone point us in the right direction please? Thanks
Problem signature: Problem Event Name: APPCRASH Application Name: prowin32.exe Application Version: 18.104.22.1683 Application Timestamp: 530654a0 Fault Module Name: DBGHELP.DLL Fault Module Version: 22.214.171.1243 Fault Module Timestamp: 4b6734ba Exception Code: c0000005 Exception Offset: 00043fcb OS Version: 6.1.7601.2.1.0.272.7 Locale ID: 2057 Additional Information 1: 7af0 Additional Information 2: 7af0855a3d2dc3b99576c539772b48b4 Additional Information 3: 2fd9 Additional Information 4: 2fd92787b378aabb7d8866897809c08e
I am assuming you meant 11.3, based on the info above. Is there a protrace file (it would be under your working directory)? You should probably log a call with Technical Support so they can assist you in troubleshooting the issue.
If Fernando's suggestion doesn't help, can you step through the code to establish where it's crashing and isolate a specific command? Is there anything interesting on the .w files that's crashing? Some sort of ocx etc maybe?
Thanks...yes, typo, 11.3
The protrace is here: I have to admit it doesn't mean a lot to me.
PROGRESS stack trace as of Fri Jan 29 13:32:40 2016
Progress OpenEdge Release 11.3 build 1333 SP02 TF02 on WINNT
-pf c:\progress\openedge\startup.pf,-cpinternal ISO8859-1,-cpstream ISO8859-1,-cpcoll Basic,-cpcase Basic,-d dmy,-numsep 44,-numdec 46,(end .pf),-pf k:\code\CSSAPP\env\live\live.pf,-db IH,-N tcp,-H 172.26.2.46,-S 16002,-trig trig,-d dmy,-T x:\,-h 10,-rereadnolock,-yy 1930,-rand 2,-Bt 2000,-mmax 16384,-D 500,-TB 31,-TM 32,-l 500,-s 500,-q,-Mm 4096,-IOEverywhere 1,-assemblies \\172.26.2.47\code\cssapp\live\ihlive\assemblies,-noincrwarn,(end .pf),-p wvCallPW.r,-Mm 4096,-yy 1990,-ininame k:\code\CSSAPP\env\live\livesys.ini,-d dmy
Exception code: C00000FD STACK_OVERFLOW
Fault address: 755A15E7 01:000015E7 C:\Windows\syswow64\kernel32.dll
DS:002B ES:002B FS:0053 GS:002B
I'm unable to step through as it crashes upon call.
Ok, so the protrace indicates that the process ran into a STACK_OVERFLOW situation. That could mean an infinite loop situation (on the ABL client process, not on your application), or some issues with paging files at the system level. It will be very helpful to try to get the full stack trace in the protrace file. That is accomplished by installing the pdb files under $DLC/bin. You should contact support for this - they can help you with getting a stack trace and this will most likely need to be reported to development so we can look into this more closely.
I just can't understand as to why the code has worked successfully with V9 & 10 of Progress and now since upgrading to V11 it doesn't - yet it compiles fine.
Definitely running the V11 compiled code James. It's got me foxed - all of our other code is fine apart from where we're using .w files that have input parameters or using a window created in app builder. We've tried saving the code via V11 app builder - syntax checker is fine but it won't run. Weird.
The protrace file isn't complete. Open a case with support and have them send you the correct *.pdb files for your version so you can put them into the $DLC/pdbfiles directory and get a better stack trace. Hopefully that will enable us to help you more.
Alternatively, you can try single stepping through the code in the debugger and see what is happening.
I've taken out the runtime parameters and stepped through the code via message boxes....the funny thing is the .w displays the screen fine when it's ran independently. However, if I call it via a run statement from the calling program we still get the crash.
The fact it displays fine when ran on it's own suggests an issue running it from a calling program?? Yet it's just a simple RUN statement that calls it - it does run it fine until it gets to the bit where it enables the UI and then we have the crash - yet like I say run it on it's own it works.
Thanks for all your help so far, much appreciated.