wrun32 crash with no dump file

Have you run a runtime trace and traced paragraphs to see approximately where the error occurs? Then add more paragraph statements to narrow the scope. Also, although it is sporadic, if you have a sample that reproduces the issue, Customer Care could send it to Development. We  have seen that debugging with Visual Studio 2012 is quite handy especially when running programs that deal with the Windows CLR.

We have done a paragraph trace in the ACUCOBOL debugger, and the results have been pretty inconsistent. I wonder if the multi-threaded nature of our COBOL application causes that. Or if we just had our eyes crossed that day.

Unfortunately we don't yet have this boiled down to a sample program where the crash can be reproduced. The actual application is pretty complex (COBOL C# JavaScript running in a Windows Forms WebBrowser control). The crash scenario involves rapidly occurring JavaScript events, for which the event handler calls a C# function, which in turn raises a .NET event detected by COBOL. The assumption is that something is not thread-safe on the COBOL side of things.

Please say a bit more about how to debug in Visual Studio. Below are a few questions.

Can this be done in the express version of VS 2012? If not, I can go work with a developer that does have the MSDN-licensed pro version.

Is a debug build of wrun32.exe required?

What are the steps for debugging in VS?

I did try attaching Visual C Express 2008 to wrun32, since I already have that installed. The status bar in VS said it was loading symbols, and then it said "Ready". Then I provoked the crash in wrun32, but nothing happened in VS.

The Windows event log showed two error events. First a .NET error:

Application: wrun32.exe

Framework Version: v4.0.30319

Description: The process was terminated due to an unhandled exception.

Exception Info: System.Reflection.TargetInvocationException

Stack:

  at System.Windows.Forms.UnsafeNativeMethods IOleInPlaceActiveObject.TranslateAccelerator(MSG ByRef)

  at System.Windows.Forms.WebBrowserBase.PreProcessMessage(System.Windows.Forms.Message ByRef)

  at System.Windows.Forms.Control.PreProcessControlMessageInternal(System.Windows.Forms.Control, System.Windows.Forms.Message ByRef)

  at System.Windows.Forms.Application ThreadContext.PreTranslateMessage(MSG ByRef)

  at System.Windows.Forms.Application ThreadContext.System.Windows.Forms.UnsafeNativeMethods.IMsoComponent.FPreTranslateMessage(MSG ByRef)

  at System.Windows.Forms.Application ComponentManager.System.Windows.Forms.UnsafeNativeMethods.IMsoComponentManager.FPushMessageLoop(IntPtr, Int32, Int32)

  at System.Windows.Forms.Application ThreadContext.RunMessageLoopInner(Int32, System.Windows.Forms.ApplicationContext)

  at System.Windows.Forms.Application ThreadContext.RunMessageLoop(Int32, System.Windows.Forms.ApplicationContext)

  at System.Windows.Forms.Application.Run(System.Windows.Forms.Form)

  at Paychex.Advantage.Scheduler.Scheduler.<.ctor>b__0()

  at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)

  at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

  at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

  at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

  at System.Threading.ThreadHelper.ThreadStart()

Then a fault in wrun32:

Faulting application name: wrun32.exe, version: 9200.4000.4.1072, time stamp: 0x546c1ff3

Faulting module name: KERNELBASE.dll, version: 6.1.7601.18409, time stamp: 0x53159a86

Exception code: 0xe0434352

Fault offset: 0x0000c42d

Faulting process id: 0x12bc

Faulting application start time: 0x01d05ff9abde6e95

Faulting application path: R:\\topps\\bin\\wrun32.exe

Faulting module path: C:\\WINDOWS\\syswow64\\KERNELBASE.dll

Report Id: fe2ea955-cbec-11e4-b286-6c626db2738f

The TargetInvocationError from .NET appears to be happening in the constructor for our .NET object. I assume that's what .<.ctor>b__0() refers to in the stack trace above. However, it doesn't make sense that the constructor would be involved, since our object was created long before this, and COBOL already has a handle to it.

However, the constructor is doing some slightly funky stuff. COBOL instantiates a class that wraps a Windows Form. A Windows Form has to run inside a single threaded apartment, so the constructor for the wrapper class does this:

           // Create a thread. The delegate's code runs when Thread.Start() is called.

           Thread thread = new Thread(delegate()

           {

               // Create the form.

               form = new MainForm();

               // Subscribe to events that are of interest.

               form.ScriptingEvent = this.ScriptingObjectEventHandler;

               form.FormClosed = this.FormClosedHandler;

               // Process the event queue for this thread in a loop.

               Application.Run(form);

           });

           // A single-threaded apartment is required for Windows forms.

           thread.SetApartmentState(ApartmentState.STA);

           // Start the thread.

           thread.Start();

Based on the .NET error, it's as if the constructor hasn't finished executing, even though it did return an object handle to COBOL. We could try moving the thread shown above out of the constructor.

We would definitely like to hear more about how to properly attach Visual Studio to our process. If this goes beyond what you can address here, then we'll open an incident for further assistance.

Thank you!

The ACU Crash Dump is created when the runtime detects something wrong. That can be something like the runtime itself detecting an error, to the OS detecting an error and signaling the runtime. In the former case, all runtime memory remains intact, and a crash dump is easily produced. In the latter case, if memory is corrupt, then the runtime may be able to try to create the crash dump, but may not be able to do so. As Steve says, Visual Studio is a better tool in those latter situations.

When you attach VS to a running runtime, you need to make sure that certain exceptions are enabled. (I don't know whether the express version of VS has this.) From the VS menu, select Debug->Exceptions. This displays a dialog. Open the Win32 Exceptions tree, and make sure "0xc0000005 Access violation" is checked. (Explore this set of trees, and check or uncheck things that may make sense. But Access violation is the most important from our point of view.)

Since you don't have the runtime .pdb files, you won't be able to get a lot of information about a crash. But hopefully something will pop out and allow you to come up with a small sample that reproduces the problem, so that you can submit it to support.

Note that the runtime is NOT thread safe. If you have multiple runtime threads running, all bets are off. You will need to restructure your application to ensure only a single runtime thread is running.