Disabling VS JIT Debugger?

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

I am not sure why an idy file is being generated for this build configuration. It should only be created if the ANIM directive is turned on. Do you have ANIM specified under compiler directives or in a directives file somewhere?

The .idy file is irrelevant to the VS JIT debugger window being displayed. This is actually controlled by a setting in Visual Studio itself and so will not occur on systems where there is no Visual Studio installed.

You can turn this off under IDE setting-->Debug-->Options and Settings-->Just-in-Time. Turn off Micro Focus Native Debugger

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

Your right about the generation of the .idy file, I don't get it on Release and do on Debug. My partner must have something screwy on his PC. We'll take a look.

As suggested I've turned off "Micro Focus Native Debugger" and now instead of getting a choice of whether to start debugging or not I get a JIT message window stating that no JIT debugger is enabled and how to go about enabling one, along with an "OK" button that when clicked clears the window and I get my Net-Express-style errors in the DOS window.

Is there any way to disable/bypass the JIT stuff entirely when running outside of the IDE?

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

In order to turn off all popups and disable JIT debugging you will have to set the run-time tunable debug_on_error=0.

The easiest way to do this is to add an application.config file to your native project by right-clicking the project name, selecting "Add new item" and then selecting "Application Configuration File". Then right- click on the application.config file that was just added and select Edit. Click on the Run-time Configuration tab and scroll down to the option "Enable just-in-time debugging" and set it's value to 0.

When you rebuild your project a file named <project-name>.exe.mfgcf will be generated in the output folder. If you deploy this along with your .exe in the same folder you should no longer get a pop message,

Thanks.

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

The application config file solution worked, but we've decided that it is too much to go back through 60 .exe projects to add them just to avoid a mouse click once in a while. Thank you for the info.

We finally got or COBOL Server up and running and, as you said, no JIT pop-ups when there's no VS.

Our transition from Net Express to Visual COBOL is going well (when the Navy isn't screwing things up with it's security measures).

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

You could also take a more global approach to turning off the JIT debugging by creating a text config file containing the entry set debug_on_error=0 and then setting the environment variable COBCONFIG_ to point to this file.

If you did this at the system level then it would be turned off for all native applications running on this computer.

I am glad that your transition is going well.

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

Navy? U.S. Navy? Please say hello to Rear Admiral Grace Hopper for us! :-)

While we are waiting for our application server to be configured we have started some preliminary testing of our application outside of the VS IDE on our development PCs. Everything runs as expected when there are no errors, but if an error is encountered then a "Visual Studio Just-In-Time Debugger" window opens and must be manually dealt with. When we click the "No" button then the error messages familiar to us from our Net Express days are displayed.

We are using VS 2013 and VC 2.3 for VS 2013 on a Windows 7 PC. Our projects are Native COBOL, Release configuration (no "Compile for debugging"), x64 platform, and linked as Dynamic with binding. The Console Application projects include system programs, the Link Library projects do not.

Q1. So why is a .idy file created on Build?

Q2. Why is the VS JIT Debugger being triggered if everything is built with no "Compile for debugging"?

Q3. Is there a way to disable or get around the triggering of the VS JIT Debugger?

Q4. Is this going to happen under COBOL Server 2.3?

Aye Aye ;-)

Sign up

Please log in or register:

Welcome to the Rocket Forum!

Please log in or register:

Scanning file for viruses.

This file cannot be downloaded