So, I am writing a Office 2010 Add-In. I have the code working and running, but would like to step through a section of code. I've added the break point and hit debug. Word starts up with the add-in loaded. This what I see in the debug window:
'WINWORD.EXE' (Managed (v4.0.30319)): Loaded
'C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll'
The program '[3280] WINWORD.EXE: Managed (v4.0.30319)' has exited with
code -1073740791 (0xc0000409).
I can interact with the add-in (Custom Ribbon), but the code never stops on the break point. I've been scouring the web and trying multiple things, but can't seem to get it to work.
Thoughts?
I don't know why it thinks the process has ended--I've never worked with debugging Office add-in's--but, in case their's no other option, you can always resort to adding a Debugger.Break() call to your code. That will force the process, when it hits that line, to bring up your debugger and let you trace through the already running process. You have to be careful to remove the line, though, before you compile a release version of your assembly.
Related
Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.
I'm building a document-level VSTO customization for an Excel 2016 workbook, and I'm encountering this error repeatedly in the development process. Basically, Visual Studio 2015 builds the project, Excel loads the workbook, and immediately Excel displays an "Automation Error / Catastrophic Failure" message. It kicks me into the VBA editor, but there's no code on the screen to edit.
I read in a few places that the error means there is something wrong with the "References" settings in the VBE, but it won't let me open that screen, the option is grayed out. Anything else I try to do just pulls that error up again. The only way out is to stop the process through Visual Studio. If I open the source workbook directly from the project folder, the same problem occurs, and I have to quit Excel via Task Manager.
This problem has been coming and going over the past 24 hours; last night and this morning it wasn't happening for some reason, so I was having no issues running and testing my project, but now the problem is back. If anyone has an idea of what could be causing this problem (bearing in mind it must be something that has not been constant over the past day), I'm all ears. Even just an idea of what to look for would be helpful, as I don't even know what this error means or what kinds of things to look for. This is my first VSTO project and I've been pretty excited by what I was able to accomplish when this error wasn't coming up every time, so I'd like to eliminate the problem permanently.
Edit: I should point out that the reason I included VSTO in the question title is that this workbook was totally fine before I started the VSTO project. But I saw this error when I tried to run the VSTO project for the first time, yesterday.
So, I think I "kinda-sorta" figured out my own problem. I'm still not 100% sure what caused it in the first place, but I'll leave this here for anyone else who runs into the same issue someday:
When you get this error, don't despair like I did because the VBE window has no code highlighted as the problem area. Look through ALL the VBA code in every object/module/sheet; in my case, I eventually found a function highlighted as the cause of the problem. I was able to bypass the error temporarily by turning off automatic calculations, and I commented out the offending function. It broke some things in my workbook to do so, but it gave me the opportunity to debug my VB.net code in Visual Studio, and when I uncommented the "problem" VBA function after doing so, it all worked perfectly fine.
When I start a debug session, program execution halts at a line that appears to be breakpoint (yellow background color). I must press F5 to continue, and the program proceeds normally.
I call it a phantom breakpoint because no breakpoint appears to be set, and even though executions stops within a loop, I need only press F5 once to proceed.
I tried setting a breakpoint at the phantom location, and removing all breakpoints but to no avail.
The only other similar problems I can find are for Java, and MS-Access where the solution was to de-compile the application.
Although this is very annoying while in development, I was gritting my teeth and baring it until the application was installed on a Citrix server where an error message box is displayed saying that a breakpoint had been encountered.
As an afterthought, I just rebuilt the setup program and after running the application, a critical error was issued. In debug mode, the message was "myapp.exe has triggered a breakpoint:". I cannot explain why it works at all on the Citrix server).
I sure would appreciate any suggestions on how to resolve this issue.
TIA
You are running somebody else's code and that code has an explicit debugger break instruction compiled into the program. You can do so for example by writing Debugger.Break() in a managed program. It could also exist in unmanaged code, the __debugbreak() intrinsic or the DebugBreak() winapi function do this. Could be a simple oversight, it could be that it was intentionally left in the code to warn about a problem.
One way to find the programmer that did this is by using the debugger. Project + Properties, Debug tab, tick the "Enable unmanaged code debugging" option. Then Tools + Options, Debugging, General, untick the "Enable Just My Code" option.
Run the program and reproduce the condition. Now use Debug + Windows + Call Stack and look at the very top of the list. Scroll up if necessary. It might well be grayed out to indicate that this is not your code, it won't be. You'll see the name of a DLL there. Call the company or programmer that wrote that DLL and ask for advice.
I always write code like this:
If SomethingIsTrue Then
'DoThis
ElseIf SomeOtherThingIsTrue Then
'DoThat
Else
Debug.Assert (False)'Doh!! I forgot to handle a certain condition
End If
In VB6 this worked great. During testing my app in the IDE, it just stopped in the Debug.Assert(False) line, and I saw where I missed something.
But VB.NET does not stop there but instead gives me a huge messagebox. This seems to be standard behaviour for Debug.Assert.
I have 2 questions, please:
1) How can I make it stop smoothly in that line instead of showing the messagebox?
2) How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
Thank you!
I would write something along this line:
if debugger.isattached=True then
debugger.break
end if
Just wrap it in a shared sub, and you can simply call it in the else statement.
The code is typed without visual studio at hand, so I hope it will work.
How can I make it stop smoothly in that line instead of showing the messagebox?
Just click Retry on the message box that pops up. From MSDN:
Clicking Retry sends you to the code in the debugger if your application is running in a debugger, or offers to open a debugger if it is not.
Clicking Ignore will, well, ignore the message.
How can I make it so that at runtime (!) no messagebox is shown but instead my application just keeps running without stopping or showing a messagebox?
I don't mean what you mean with at runtime, since all asserts happen while your code is running, hence at runtime.
If you mean that asserts should be ignored while running your application without a debugger, just make a release build instead of a debug build. The Debug.Assert method works only in debug builds, and the point of debug builds is that they are easy to debug.
If you want nonetheless suppress the message box, see Customizing Assert behavior:
For example, you could override the TraceListener.Fail method to write to an event log instead of displaying the Assertion Failed dialog box.
To customize the output in this way, your program must contain a listener, and you must inherit from TraceListener and override its TraceListener.Fail method.
I'm buisy on a DirectX10 game engine and i'm having a problem which has nothing to do with DirectX :P The problem is that in the DLL which contains the engine sometimes a DialogBox is called, just like you would do in normal win32. With the only difference that instead of the HINSTANCE i use the HMODULE which i get when loading the DLL.
Everything seems to be working fine, if i step through my code with F10 (Visual C++ 2008) i can even see it going through my DlgMessageProc function and do everything it should do. The only weird thing is that no dialog is shown and that all of a sudden it jumps out of the message loop and just continues with the rest of the code???
Weirly engough I have the same problem when calling MessageBox from inside my DLL, I get no errors, everything seems to be working fine but no window is shown, nor is the code halted (as normal with messageboxes)
The funny thing is that I have some code from a book which uses the same basic architecture as me and if i compile that everything shows just fine??
So my question, is there any hidden option, pragama comment or other thing i should look at if i want to be able to show MessageBoxes and Dialogs from my Dll?
No as i thought, chaning the manifest doesn't help at all. I also created a separate project where i just test the dialog and its proc function and there everything works perfect (links to a .exe instead of dll)
In the visual studio resource editor's property page for the dialog resource there should be an option in which you can specify - "No Fail Create: True".
Usually dialogs fail to create because a common control cannot be created - usually because InitCommonControlsEx has not been called. Setting the No Fail Create flag lets you see dialog and determine which controls are missing.
Other things to check:
Is there a message in the debug window about a first chance exception? Perhaps its 'jumping out' because of an exception that is being caught and silently handled by Win32. Turn on debugging of first chance win32 exceptions in the Dev Studio exceptions dialog to track that down.
Even this wouldn't explain how a MessageBox call would fail to create a message box.
The only times Ive seen MessageBox fail to work were when:
Resource leaks had made the process run out of available user32 handles - have you checked your apps handle counts using task manager?
the system was in the process of being shut down. Have you called PostQuitMessage and then tried to create a dialog/MessageBox?