I'm debuggin on started Visual Studio 2017 after remotely logged into the server (Windows 2012 R2, 64-bit) via RDP. Note: so this is a "local debugging after remote login" issue, not a "remote debugging" issue.
Normal C++ project debugging is fine. But I'm working on an Excel plugin, so set the project's property at debugging > command = ...excel.exe. By right, after I started VS debugging, VS shall trigger excel instead, then, if excel loads the project as a plugin and make calls to it, VS can trap the break points.
However, this is now not working: Excel started then exited, before any of my c++ code is called. VS output says there’s an Roaming::RoamingCacheException error:
Exception thrown at 0x00007FFAB71968D8 in EXCEL.EXE: Microsoft C++ exception: Roaming::RoamingCacheException at memory location 0x000000D00613A3E0.
If I start excel first, then attach VS to the process by in vs menu debug > attach to process, then VS can successfully hook to excel -- this is now my work-around -- just to say VS or my code has nothing wrong.
As the exception happends during loading Excel, calling ntdll.dll, I suspect, something is wrong with the user profile caching for remote login (roaming).
But I'm not familiar with this part, any suggestion?
Related
I cannot get dump files created with Task Manager (32 or 64 bit) or Process Explorer to give useful results in WinDBG or Visual Studio 2015, whereas the dump written directly from VS works brilliantly in both. I need Task Manager dumps to work so that I can analyse dump files sent by my end users.
I have reduced the problem to the simplest possible Win32 application, created in VS 2015 C++, with a deliberate NULL pointer write to cause an exception. If I run the program in VS and use Save Dump As when the exception occurs, then the dump file can be used in VS and WinDBG to see the code causing the problem. This is as expected.
However, if I run the application outside of VS, then Windows shows the usual dialog:
“Win32Project.exe has stopped working … Debug / Close Program”.
Whilst this dialog is still active I go to Task Manager 32bit and select Create Dump file. But loading this dump file into VS or WinDBG gives no useful information. In particular VS shows Exception Code as “not found”. Clicking on “Debug with Native only” causes “The application is in break mode to be shown”. See below…
I am running a new Win 10 64bit PC. DMP, PDB and EXE files are in the same directory, and I have tried endlessly with symbol directories
Visual Studio 2015 output after loading .DMP file:
Dump Summary
------------
Dump File: Win32Project1 (4).DMP : C:\Users\Rob\AppData\Local\Temp\Win32Project1 (4).DMP
Last Write Time: 24/08/2017 16:38:27
Process Name: Win32Project1.exe : C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe
Process Architecture: x86
Exception Code: not found
Exception Information:
Heap Information: Present
System Information
------------------
OS Version: 10.0.15063
CLR Version(s):
Modules
-------
Module Name Module Path Module Version
----------- ----------- --------------
Win32Project1.exe C:\Temp\ConsoleAp2\Win32Project2\Debug\Win32Project1.exe 0.0.0.0
ntdll.dll C:\Windows\System32\ntdll.dll 10.0.15063.447
kernel32.dll C:\Windows\System32\kernel32.dll 10.0.15063.296
...
Why does that happen what you see?
It works in Visual Studio because the debugger is already attached. The debugger is informed about the exception before the process terminates. The debugger will halt the process before the Windows Error Reporting Dialog occurs and create a crash dump when the original exception is still active.
To learn more about the process on how exceptions are passed from the program to the debugger (first chance), back to the program (catch block), to the debugger again (second chance) and finally to the OS, google for the term "exception dispatching".
It does not work with Task Manager, because exception dispatching is already in its last state, which is "get handled by the OS". This makes Windows halt the program by making use of a breakpoint. It then shows that dialog. When you create a crash dump now, it's too late and it's very hard to get useful information from that crash dump.
What options do you have?
a) Windows Error Reporting
The mechanism that applies here is called Windows Error Reporting. If you had an account at Microsoft, your customer could simply click the "submit" button. You would then get some information from Microsoft. The way you ask the question makes me assume that you don't have such an account.
Then, use a feature called LocalDumps (MSDN). It's a Registry key to configure Windows to save a crash dump on disk. Make sure you understand what you need from such a dump in order to configure it correctly. In doubt, have a look at How do I take a good crash dump for .NET and use the same settings (full memory user mode mini dump). It will be good for C++ as well.
It might even be possible to activate this Registry key while the dialog is shown but I have not confirmed this any more since 2014 and I can't recommend it.
Check if your settings work by using your null pointer dereference sample application. To do so, rename your executable to the same name as your actual program.
b) Attaching a debugger
Attach a debugger to the process, then let the application continue. Press "Debug" on the dialog and confirm the message that says "a debugger is already attached". The second chance exception is thrown again, the debugger will get it and you can take a crash dump.
If you need screenshots, see my article about it
Note that in approach b) you can make many mistake which will lead to improper results. The safe way is to activate LocalDumps as described in a)
I recommend giving ProcDump from Windows Sysinternals a shot. You can set it to capture a dump of your app when it crashes, or set it as the Just-in-Time debugger and have it write a dump for any app crash.
See the documentation and examples in the above website for more detail.
I have mfc application that working fine on the machine with VS 2013 pro. But when I try to run it on the other pc which has VS redistribute package 2013, VS remote tools. Nothing happening. I can see in the task manager that it is started but then it goes away...
What I have tried so far:
1) I used Dependency Walker to find dll that my application depend on. And for my setup project I add MSVCR120.dll, the rest of the dll's were mfc120.dll the ones that part of the OS i didn't add it them, because I got warnings if I'll add dll which is part of the OS and another PC has exactly the same Windows 7 so they are on the PC.
2) I used VS remote debugger, and at this time I got this First-chance exception .. _com_error at memory location. But I can't catch it. I don't know where to look. My call stack look's that this.
3) Last out put before error, says that sqloledb.rll was not loaded, I check it systems folder does have it, I even copied to the folder where application executable located, still does not loaded, still have exception.
Can any one point me to what can cause this error or why application does not run? What else to install so my application can run the same way it is run on the machine with VS. It is seems that this error rise often but none of the solution helped me.
I used procmon.exe and it is shows buffer overflow.
It is turn out to be database connection. Application quite on this line, so I add try/catch block. But shows "unexpected error"...
m_pAppConn->Open("File Name=MyData.udl", "", "", adConnectUnspecified);
m_pAppConn is a _ConnectionPtr. On my pc I have MS SQl Server Enterprise, but on target pc MS SQL Express, could it be the issue?
I am using the new MessageLoop class introduced in pepper-25 so I can run a background thread with blocking ppapi calls for File IO. Up until now I have been running chrome from visual studio with the flags --single-process and --register-pepper-plugins so I can debug my plugin from within visual studio.
Using these flags I found that the call to PPB_GetInterface get_browser for PPB_MESSAGING_INTERFACE was returning null and after some searching I found this issue which states you must run with the flag --ppapi-out-of-process to get MessageLoop support.
With that flag added get_browser does return a valid interface pointer but I can no longer debug my plugin with the visual studio ide as it cannot attach to the child process that my plugin is run from. Is there anyway to tell it to attach to my plug-in process or a way of running from a single process with support for MessageLoop?
Thanks,
James
To get Visual Studio to attach to child processes automatically, you can use the workarounds described at Can Visual Studio be made to debug child processes like WinDBG?.
A different approach is to use the flags --no-sandbox and --ppapi-startup-dialog when you start Chrome. This will cause a message box to appear with the process id when a plugin process is created. You can then connect the Visual Studio debugger to that process using Debug -> Attach to process... -> pick process id. Of course, you could have attached to the process without the Chrome flags and it's not automatic, so this really just gives you certainty that you're attaching to the right process if you have many running at the same time.
A third approach is to use the free Microsoft-provided debugger WinDbg. It is complex and much less user-friendly than the built-in debugger in Visual Studio, but it does have the ability to attach to child processes automatically. Download is available from http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx.
As for MessageLoop it will not be supported for in-process plugins. As the issue you link to mentions, developers should move to out-of-process, even if it adds the inconvenience of not being able to attach the Visual Studio debugger automatically without workarounds.
I have a Visual Basic 6 application that I've recently changed to use a couple of C++ DLLs I've written in Visual Studio 2008. The application works fine on my PC, but when we install it on one of our test PCs it tends to crash during shutdown - we see the Win 7 message "Your application has failed" or whatever it is.
I know Win 7 stores data that can be used to analyse the crash. I've got the source code and .PDB files from the build so I should be able to use that, but I can't figure out where Win 7 stores the data from the crash. The Event Viewer shows the crash but doesn't have any data and the directory C:\Windows\Minidump doesn't exist.
Where do the crash files get put?
Microsoft has documentation here which works back to Vista Service Pack 1:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs.85).aspx
There is a registry key with 4 sub-values that control generic crashes:
# HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
DumpType # 1 = mini-dump, 2 = full dump, 0 = custom dump
DumpCount # Maximum number of dump files to keep before purging
DumpFolder # Full path to folder to store dump files (no trailing slash)
DumpFlags # Usually 0, flags only used if DumpType is 0
Once these registry values are in place crash files should be immediately written no matter what happens to whatever dialog might be displayed.
Note: Registry sub-keys with executable name can be used to control crash behavior for only one specified process.
Get minidump for crash
Get WDK , Using Debugging Tools for Windows
Use Windbg to open crash dump
use command !analyze
The !analyze extension displays information about the current exception or bug check.
Read more about window debugging
Creating Dump:
You can configure windbg as defaut debugging tool by giving command "windbg -I" in run.
Also Dr. Watson tool can do this for you.
You can even use a carsh reporting mechanism and get the locally saved dump file, then debug it using Visual Studio. There are pretty much freely available resources in Visual C++, but not much in VB.
Why don't you make your program save minidump wherever you want when the crash happens? I'm not familiar with VB, but try to use SetUnhandledExceptionFilter() and MiniDumpWriteDump().
Creating a WCF Service Library in Visual Studio 2008 on Vista x64 is troublesome when referencing an x86 DLL. A service that calls a 32-bit DLL is required to have a platform target of x86 to run on a 64-bit OS. When you do this, the WcfSvcHost throws a BadImageFormatException when you attempt to debug the service. There is a bug report on MS connect. The workaround I used was to coreflag WcfSvcHost as 32-bit.
Manifest Problem
The main issue I've run in to is this third-party native 32-bit DLL fails to load using certain WCF hosts. I receive the following error when a service operation is invoked that uses the third-party DLL:
System.TypeInitializationException: The type initializer for
'' threw an exception.
.ModuleLoadExceptionHandlerException:
A nested exception occurred after the
primary exception that caused the C++
module to fail to load.
System.BadImageFormatException: The module was expected to contain an
assembly manifest. (Exception from
HRESULT: 0x80131018)
NestedException:
The handle is invalid. (Exception from HRESULT: 0x80070006 (E_HANDLE))
This exception is not raised when WcfSvcHost starts, it's raised when the a service operation is invoked that references the 32-bit DLL. What's very interesting, hosting this same service with the same app.config on a console app has no exceptions and works perfectly:
using (ServiceHost host = new ServiceHost (typeof (MsgBrokerService))) {
host.Open ();
Console.WriteLine ("running");
Console.ReadLine ();
This exception occurs right after:
'WcfSvcHost.exe' (Managed): Loaded
'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_
none_d08d7bba442a9b36\msvcm80.dll'
Again, the console app does not have an exception and loads the same DLL:
'ConsoleApp.vshost.exe' (Managed):
Loaded
'C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.3053_
none_d08d7bba442a9b36\msvcm80.dll'
See answer from Microsoft Product Support.
Update #1: Both the console application and the WcfSvcHost.exe host process runs under the same session and logged-in user (me). I've copied WcfSvcHost.exe to the directory of the service, manually launched and experienced the same result. I've also checked the Windows Event Log for additional information and used sxstrace, but nothing was logged.
Running Process Explorer, I've verified the following are the same between the two processes:
Image: 32-bit
Current Directory
User/SID
Session
Security (groups denied, privileges disabled)
Running Process Monitor, and configuring symbols, I see WcfSvcHost looks for the following registry and files, while the console host does not. Process Monitor logs a lot of data and I'm not sure what I'm looking for :(.
HKLM\SOFTWARE\Microsoft\Fusion\PublisherPolicy\Default\policy.8.0.msvcm80__b03f5f7f11d50a3a
C:\Windows\assembly\GAC_32\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
C:\Windows\assembly\GAC_MSIL\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
C:\Windows\assembly\GAC\msvcm80\8.0.50727.3053__b03f5f7f11d50a3a
Update #2: This same exception occurs when the service is hosted in production on IIS 6 / Windows Server 2003.
Update #3: The 3rd-party 32-bit .NET assembly is the StreamBase API:
sbclient.dll (managed)
monitor.netmodule (managed)
dotnetapi.dll (unmanaged)
pthreads-vc8.dll (unmanaged)
Update #4: Added manifests without success:
Verified that dotnetapi.dll and pthreads-vc8.dll have RT_MANIFEST. The sbclient.dll .NET assembly did not have a manifest
Removed sbclient.dll from the GAC
Registered sbclient.dll for verification skipping
Added a manifest via mt.exe to both sbclient.dll and monitor.netmodule
Verified manifest was added and that the expected files were loaded during testing (via Visual Studio - debug modules window)
The same BadImageFormatException is thrown under BackgroundWorker.OnDoWork(), and the call stack shows a call to dotnetapi.dll...DefaultDomain.Initalize().
I have verified that msvcm80.dll does not have a manifest, I believe this is the only file loaded that doesn't have a manifest :)
Interesting find
When I load monitor.netmodule in Reflector, it says:
'monitor.netmodule' does not contain
an assembly manifest.
Even though it displays an error, Reflector is still able to disassemble the managed code.
a bit late but you can also change the app pool setting "Enable 32-bit Applications" to true in advanced settings.
Microsoft Product Support has resolved this question: It's by design. The unmanaged code is not loaded in the default AppDomain when using WcfSvcHost or the IIS WCF host.
A pure image will use a CLR version of
the C run-time library. However, the
CRT is not verifiable, so you cannot
use the CRT when compiling with
/clr:safe. For more information, see C
Run-Time Libraries.
http://msdn.microsoft.com/en-us/library/k8d11d4s.aspx
I cannot provide an explanation for the error, only my initial suspicion that there is a permission difference between the context in which your code is run as a service and the context in which it is run when you place it in a console application. The E_HANDLE HRESULT is my clue here. Assuming that you run the console application as your logged-in user, you could try configuring the service to start as that user as well. If it works in that configuration, then you can attempt to narrow down what required resource is unavailable when it fails.
I can suggest a workaround. If there is an oddity of the DLL in question that prevents it from working in a hosted service, you can take the sacrificial process approach, so named because it is typically used to isolate a DLL that crashes often. Briefly, you create a proxy program whose only purpose is to load and call the DLL on behalf of your main process, using named pipes or some other IPC method to pass requests and results. If the DLL crashes, you start a new instance of the proxy program. In your case it would have the added benefit that only the wrapper program would need to be 32-bit.
Do you see anything special in the Event viewer?.
In Vista if there a manifest problem you will see traces of it in the Event Viewer, it will tell you to use SxsTrace.
Could you manually add a manifest to this DLL yourself, using the mt.exe file?
MSDN Article on using mt.exe
This may seem a bit dumb; but make sure your service is running in the correct application pool.
Ran into this issue myself. I found a helpful post. As noted in other posts, Microsoft stated this is by design. Basically you need to:
Locate your version of WcfSvcHost.exe. (for me and visual studio
2017: C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE)
Launch developer command prompt
Execute cmd: copy C:\SourcePath\WcfSvcHost.exe
C:\DestinationPath\WcfSvcHost32.exe (Destination doesn't matter)
cmd: corflags /32BIT+ /Force WcfSvcHost32.exe (may need to cd to DestinationPath
In visual studio open the WCF project properties > Debug tab > Start External program: C:\DestinationPath\WcfSvcHost32.exe
Also add your command line arguments:
/service:MyWCFProjectName.dll
/config:MyWCFProjectName.dll.config
Note: You do not need to use ($ProjectDir) here
Launch the app. You are now free to launch WcfServiceHost.exe seperately.
Optionally go to solution > Set Startup Projects > Multiple Startup Projects > Choose the Wcf project and the client project.