I was given the source to a transport agent that parses incoming email that meet a certain criteria. I need to make some modifications but I need to track variables and my debugging attempts have been unsuccessful.
I build the dll, install it in exchange, set a break point then attach to the relevant process but nothing appears to be happening. I am not experienced in this method of debugging and I'm pretty sure that i'm missing a step, but all the documentation i'm able to find basically has the process listed as those few steps. Any assistance?
Figured it out
For anyone in the same situation, you need to do is this:
Compile your project in Debug mode.
Deploy it to exchange however you do that.
Since it is a DLL and running through exchange, exchange will be the host process so you'll have to attach a debugging to the exchange process for debugging.
You can do that but going to the Debug menu in VS and selecting "Attach to process", select the process that will be running the DLL.
When VS attaches to the process just set breakpoints in your code and you should be good to go.
Related
From a lot of our customers, we have been getting complaints that Outlook unexpectedly crashes (complete process restart) when using our plugin.
So far it has been impossible to reproduce, we can only analyze the logs after the fact and the only thing we know so far is that if we turn one specific add-in off, then the problem stops (it's a local add-in that helps sending e-mails with a configurable template). This add-in runs on .NET and is written in C#.
We have spent weeks gathering and analyzing logs. The crash always reports an Event ID 1000 in the Event Log, which points the faulting module to kernelbase.dll / olmapi32.dll / wwlib.dll / ntll.dll.... or some other dll file. The crash happens on several Outlook builds, old or new, monthly channel or semi channel, doesn't matter.
From our code we were finally able to simulate one crash after running an analysis in VisualStudio which warned us about some potential NullExceptions, when testing with that we could simulate one Outlook crash pointing to Kernelbase.dll. We now fixed this in a new patch and still awaiting results from customers, but in the meantime are there any more options to debug such a random crash? Hope anyone can help us here.
That is a widely spread problem when dealing with Office COM add-ins. The problem can be related to other add-ins, not only yours. Even to locate the source of the issue is very complicated in such cases. You can generate a dump crash and then analyze it to identify the source, but it may not help well because changes made by any add-in may not be detected following that way - the exception which could lead to the crash can be thrown by Outlook itself. For example, a badly written COM add-in may release a COM object and then finish its works, then at some point the host application detects that a required COM object is disposed and cannot continue execution, so it crashes suddenly.
To identify the source of the issue, first of all, you need to add any logging mechanisms to the add-in and see where and when the issue takes place. Then you can try to start simplifying the source code of your add-in by commenting line by line and seeing results after whether it helps or not. It also makes sense to try a newly created add-in, so it can be sure the issue comes from any other add-in, not your own code. There are a lot of helpful steps that could be made, but they depend on the specific scenario you deal with.
You can enable Outlook logs as well. Read more about that in the How to enable global and advanced logging for Microsoft Outlook article.
Try to collect a crash dump using ProcDump.exe and then open it in windbg.
Download ProcDump from
https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
and run the following from command line:
procdump.exe -e -ma -o -w outlook.exe
I've got stumped by problem during development of my ASP.NET application.
I cannot debug it any more after attaching debugger to a process. Recently I was changing some windows features and checking IIS settings but as far as I remember I was able to debug my app till today.
Ok so what's going on.
I attached debugger and nothing happens no symbols are getting loaded (I am absolutely sure that Build -> Configuration and stuff looks correct in terms of debug etd). That symbols are getting generated and that app is working on dlls which I compile the only problem is that no matter what I do - symbols are not getting loaded.
I've got 2 traces which could lead me to the cause 1st:
The first one is strange application type when attempting to attach a debugger using visual studio. Normally all other apps are using Managed (v4.0......),x64 (I am right now talking about Window with all process running on computer Debug -> Attach -> type column)
but this app for some reason is using Script, Managed (v4.0......),x64
The other one is that when I've debugger attached to the application and open Debug -> Windows -> Modules the only one that is listed is:
**Script Code (Microsoft Active Server Pages) Script Code (Microsoft Active Server Pages) N/A N/A Symbols loaded. Script Code (Microsoft Active Server Pages) 1 [29896] w3wp.exe**
Which kinda looks like some precompilled stuff. (I do not recall enabling any kind of recompilation).
I've tried recreating app on IIS along with switch app pool yet it's still the same. What's even more after checking diff of web config I don't see any kind of change which could lead to such behavior.
I was working with this application for like 8 months and never had a problem like this.
Thanks in advance for your tips.
Kind Regards.
EDIT:
Images
Modules
I've had the exact same issue and could solve it by moving the site to a different application pool. The target application pool already had an application assigned which I could debug (showed up as Managed (v4.0......),x64 in process selector) and once I moved the problematic site over, I could also debug that site.
I didn't figure out what exactly causes the behavior in the first application pool but maybe this helps someone to quickly solve this problem until someone comes up with a better analysis.
I'm having trouble with real time debugging of a Windows service on a remote machine. This machine is behind a firewall only accessible through remote desktop. I include Debug.WriteLine statements through my code, in lieu of Console.WriteLine. Not too long ago I ran across an application from Microsoft named Debug View. It has been helpful in debugging Forms and WPF applications but it will not show the Debug.WriteLine statements for a running service. I would be extremely happy if I could see these debug statements. Is there a way to do this?
Note, the project is compiled in debug mode as I can see the debug statements in Debug View during the service installation.
Run Debug View as Administrator, select the Capture menu, then make sure that Capture Global Win32 is checked. That will capture Debug.WriteLine output from your service (and any other service as well). You may want to use a filter to prevent Debug View from displaying output you are not interested in. Consider prefixing your service debug messages with your service name so that you can filter for them.
I've written a shell extension using EZShellExtensions.net. It works great in my development environment when I'm logged in as me, as well as any other system when logged in as me. For all other users, the copy-hook I've created never appears. I've used NirSoft's RegDLLView to verify that the DLL is registered, but no luck.
What can I check to see why this is occurring?
FYI
I'm happy to send a copy of my code to whomever wants to help out with this. EZShellExtensions.NET has an evaluation period of 30 days.
UPDATE
ProcMon Output when using the vendor's registration tool now available as a CSV/PML file if anyone's interested.
RESOLVE
I wound up adding console output to the dll for debugging. turns out that a timer wasn't kicking off when running as any user but me (no idea why). This has since been fixed.
That indicates that the shell extension got registered in the HKCU\Software hive instead of HKLM\Software. Only the latter hive makes extensions available to all users. This commonly happens because UAC prevents writing to HKLM\Software unless the program that does the writing is elevated.
If this library comes with a dedicated registration program, they usually do, then be sure to run it from an elevated command prompt. Start + All Programs, Accessories folder, right-click the Command Prompt link and click "Run as administrator". Rerun the registration tool.
If you still have trouble then SysInternal's ProcMon tool can show you exactly where stuff gets written. And don't hesitate to use the vendor's support channels.
I was wondering if there was a way to completely lock my code while debugging it within Visual Studio 2008. The code documents lock automatically when running as 64 bit applications, which I greatly prefer; however, I do most of my coding making add-ins for Excel, which is 32 bit. The result is that even though I target 'AnyCPU', the VS host knows that it is running within a 32 bit process and, therefore, the source code is not locked while the code is running hosted in Visual Studio.
I can turn off Edit and Continue by going to Tools > Options > Debugging > Edit and Continue, and then unchecking the 'Enabled Edit and Continue' check box. This does not completely lock the code, however. This does prevent any edits in the code from being executed in the current run, but it does not prevent mouse clicks or keystrokes from actually changing the code.
Again, when working with 64 bit applications this does not occur -- the code is completely locked. I greatly prefer the code to be completely locked for at least a couple of reasons:
I can accidentally hit a key or the like while debugging, which I definitely do not want to do. It's rare, but it is an issue.
Many of my automated tests drive the user interface via SendKeys. When stepping through such a test using the debugger, however, I can sometimes forget that some of the aspects involve SendKeys, which means that keystrokes wind up getting sent to the Visual Studio IDE instead of Excel.
In issue #2, above, the unit test fails, which is fine -- my bad -- but having all the keystrokes sent to the code module and destroying my code is completely unacceptable.
Does anyone have any ideas here? Can one completely lock the code when running hosted in Visual Studio while compiled against a 32 bit CPU?
Some related posts on this issue, but none of which directly address this:
How to: Enable and Disable Edit and Continue
“Changes to 64-bit applications are not allowed” when debugging in Visual Studio 2008
How do I enable file editing in Visual Studio’s debug mode?
How does “Edit and continue” work in Visual Studio?
Can we edit our code while running the application
Editing C# while debugging
Thanks in advance for any help or ideas...
Mike
Here is a trick I use under Visual Studio 2005 (don't have a chance to test under Visual Studio 2008, but it should work):
Open the executable assembly's properties
Go to the Debug tab
Check the Enable unmanaged code debugging checkbox
The code documents should stay locked, even when a breakpoint is hit, and any attempt to change it should trigger a popup saying "Changes are not allowed when unmanaged debugging is enabled".
Hey there - sorry I can't help you with completely locking your code - I have the opposite desire: to completely UNLOCK it during debug, but I can help you with your second issue.
I suggest that you consider checking the active window before sending any keys and if the active window is other than your target site, pause the execution of your test until focus is returned that that window.
I know it's not the solution you want, but it probably wouldn't hurt to prevent other similar issues.
Best of luck!
Adam
Here is the best I could come up with. It works, but there are some steps you may not want to take.
Essentially, the technique is to set the files of your project to Read-Only when you run the application, and then set them back to writable once your application ends.
However, in VS2k8, by default, setting a file to Read-Only still allows you to edit the file. You need to first turn off the setting "Allow editing of read-only files..." in Tools > Options > Environment > Documents.
Second, you need to add the following key to the registry as a DWORD and set its value to 1:
HKCU\Sofware\Microsoft\Visual Studio\9.0\Source Control\UncontrolledInMemoryEditDialogSuppressed
This still won't work completely. What you then have to do is set your Source Control for that project to Visual Source Safe. (<-- this is the step I'm assuming you won't like.)
Then restart VS2k8.
At this point if you set one of your files to read-only, you will see that Visual Studio will not let you edit this file at all. When you try, it plays your computer's exception music.
Now, to make your files read-only when you run the app, set a post-build process to do this. That's easy.
Harder, is to set them back to writable once your app finishes running. The simplest solution is probably a batch file shortcut.