I'm trying to debug into a C dll that is invoked on a Windows Mobile device using CeRapiInvoke() (Technically RAPI.Invoke() from OpenNETCF) from a Windows box. I'm very familiar with attaching to a process that is already running to debug a loaded dll (I've done it many time with Windows Mobile services) but I can't seem to figure out what process is actually running the dll. Even when running the Remote Process Viewer I don't see any new processes pop up, so it must be something that is already running... Any ideas as to which process to attach to in order to debug into the dll when invoked?
Edit: After trying to attach to several different processes I found that it was "rapiclnt.exd" that did the trick.
rapiclnt.exe is the process which loads the RAPI dlls. Read this for more on debugging RAPI dlls.
http://knowledgepointer.wordpress.com/2008/11/08/debugging-rapi-dlls/
Related
I just installed a Windows 10 machine, since Windows 7 is now dropped... along with the old, classic VC6. Plus the Service pack 6, and the Platform SDK installed. I have been using it this way with no issues on my Windows 7 machine for decades (too long to go into why not upgrade to VS 2010, 2012, 2015, 2017, 2019, yada yada, yada... Subject for a different debate)
I brought up an existing project I was working in before the end of the year. Big exe, several DLLs in it, C++ objects, etc... Was all working fine before Jan 1st.
On my new Windows 10 install, when I tried to launch it in the debugger, it gave an error:
This appears even before main is called. And the executable immediately exists, even before the message box appears, so there is no stack trace to examine. Naturally I looked for any C++ constructors that might be called which could be corrupting things. But there were none. (and never had any issues on my Windows 7 machine anyway)
I narrowed it to the following condition:
The main EXE is linked statically to a LIB/DLL. THAT dll is linked statically to another LIB/DLL
When I remove the underneath DLL dependency, I can run the executable in the debugger.
I've found several projects that are experiencing this.
I have a test project (dsw and dps files) which demonstrates this (at least on my Windows 10 machine) if anyone wants to look at it. It is stripped down to nothing but shells. An EXE that is linked to a DLL, which is linked to another DLL. If I remove the inner DLL dependency in the link stage, the executable with a single DLL work fine.
Also, the EXE will run outside the debugger as well. Both debug and release.
Lastly, when I set the configuration for release, it also runs in the IDE, but has no debug info. However if I enable debug info in the release builds, it again crashes before startup.
So apparently there is yet something in windows 10 that is preventing the debugging container from running. I have also disabled the "Fault Tolerant Heap Shim" but no change.
Has anyone experienced something like this?
Does anyone have any advice?
-Scotty
I've been living without our V6 debugger for a few years now, and after doing yet another search hoping for a solution where I wound up here, I finally found a way and wanted to share it. For projects that give a user breakpoint error and exit immediately on startup, launch them with Build->Execute (ctrl+F5), then do a Build->Start Debug->Attach Process. You won't be able to do anything about the startup, but you can set breakpoints at timers or commands to get in. I guess you could put a long sleep as the first call in your main while debugging to give you a chance to get in and get your breakpoints in place there too.
On a Windows 7 x64 I have have written an application which also includes a .dll which is installed to the GAC. This has been working without error for about 3 years. I recently made a new version of my Application but did not change the version of the .dll. The application starts at boot time and now I get a message from Windows...
Caution ... You are attempting to open a file of type "Application Extension" .dll
And then it wants you to choose a program to run it with.
I uninstalled this version and installed my previous version and I do not get the error.
I have no idea where the problem is so my tags are an attempt to get the ball rolling. Wix is my installer program which might have something to do with it.
How is my Application started at boot time
There is a registry entry in \Software\Microsoft\Windows\CurrentVersion\Run which has a path to the Application's .exe file. This Applicaion has the dll as a reference.
So if you remove it from autostart and start it after the pc is fully up, does the same message appear ? If that worked, a workaround would be registering your app as a service and set its startup to delayed.
When i googled your error some malware- threads came up. If you straight up load your dll and its unsigned e.g. via rundll32.exe that might cause an issue - but i dont entirely know how your autostart-entrypoint looks like.
I am currently developing a Windows Store App that will eventually be targeted at the ARM devices when they are available. For now, I have been developing and testing from Visual Studio on my desktop computer and everything works fine. However, when I try to create an app package that I can pass along to others within my company for testing purposes, the application will not run properly.
The solution includes two projects. The first is a C++ project that is set to build a dll file. The purpose for this is to expose the Direct2D and DirectWrite libraries that seem to be unaccessible to a C# project. The second project is the C# project that references this dll for drawing functions and includes a XAML interface and most of the program logic. All of this works flawlessly on my development machine from within Visual Studio (and also when installing the package).
When I send the package files to other individuals within the company, the installation appears to work fine by installing with the PowerShell script. The tile appears in the start screen and the program will launch for a few seconds. The C# and XAML interface appears, but the DirectX portion of the application is not visible and the entire application shuts down within a few seconds. This makes me believe that the dll may not be installing or referenced correctly upon installation. I have checked the package file, and the dll file is included in the package after the build process is complete.
I have packaged a few different test programs (MSDN Samples) that have all installed on their machines, but we get the same results that they will not run (again, all samples run fine on my development machine when building them). The only test project that worked properly was a simple C# project that did not use DirectX at all. Any of the DirectX samples that I tried have all failed (including the native C++ samples that do not use C# at all).
To be clear, the process I use for building is going to Project -> Store -> Create App Packages and choosing the No option for uploading to the Windows Store.
Does anyone have any ideas on what might be going wrong with the build or installation process?
Thanks in advance for any help!
Does it work with the Metro Sideloader? I am not sure if it just adds a UI to the Powershell script, but it works for my team and me for testing...
Good luck!
Are you side loading a Debug version of your DirectX app onto a machine that does not have the Windows SDK installed? Visual Studio's default DirectX projects and the samples on MSDN both request the D3D11_CREATE_DEVICE_DEBUG flag when creating the D3D Device. Device creation will fail if the Windows SDK is not installed on the machine running the code.
Here are a few different options that will allow you to unblock yourself. Any one of these should give you the desired result:
Create a Release package and deploy that instead of a Debug package.
or - Go to DirectXBase.cpp and remove the D3D11_CREATE_DEVICE_DEBUG flag from the code.
or - Install the Remote Debugging tools for Visual Studio on the target machines. This will install the necessary SDK components to allow creation of D3D Debug devices. The other cool thing about this option is that once you're set up you won't have to create packages manually and side load them anymore. Just tell Visual Studio the name of your ARM machine and press F5 to deploy it remotely. More information here: http://msdn.microsoft.com/en-us/library/vstudio/bt727f1t.aspx
How are you deploying the native DLL with your project? Are you using project-to-project references? Can you verify that your DLL is ending up in the final package, in the root of the package application directory?
I recommend using Sysinternals Procmon to watch your application load on the target machine. If it crashes or fails, you can look in the log history for which DLL it is trying to load and failing. Typically this will show up as a repeated series of DLL load probes (it will try and load the dll from the application directory, and then proceed to try a number of other paths).
** post was edited, more info below
I've just watched two great videos about Advanced Dotnet Debugging (by Brian Rasmussen) and I am trying to repeat some steps, but just don't know how to proceed with tis error:
An attempt to set a processes DebugPort or ExceptionPort was made,
but a port already exists in the process.
I've found some answers on google and i generally understand what the error says but I just don't understand one weird fact: when i compile my simple app < .NET 4.0, I can attach as the movie shows, trying to do the same after i compile targetting .NET 4.0 disables me from attaching.
One of google's answers says "try to attach from windbg using noninvasive mode" but.. Brian do not use any of such checkboxes. It just works on his videos.
What's the difference? Where's the catch? Is it Windows 7 vs Vista? Maybe some different compile settings matters?
I am using MS VS 2k10 with MS SDK with Windbg x86 downloaded from msdn and symbols correctly configured to http server. The system is MS Vista x86.
Resources (exact time >= 8:15):
http://channel9.msdn.com/posts/MDCC-TechTalk-Advanced-NET-Debugging-part-2
Edit:
Error shows when attaching to process that was run from VS. Trying to attach to process that was run /outside VS, windbg doesn't show any content.
Edit2:
Windbg had some refreshing problems in my system. Using few times "Windows \ [Undock | Dock all]" menu option i was able to see the content of attached process, that was missing.
So the only question now is: what's the difference when attaching to process started from VS, when it's compiled in once using target < 4.0 and again = 4.0? Why when targetting 4.0 windbg cannot attach to the process in not "noninvasive" mode. What has changed in VS 2k10?
I take it you're debugging from Visual Studio (F5) and then trying to attach. You can only have one active debugger at a time, so that is why you get this error. If you want to launch the process from VS, run it without debugging (Ctrl-F5). If you do that, you should be able to attach from WinDbg.
EDIT : I am sorry, I missed the point about various versions of .NET behaving differently in this respect, so let me try to address your questions again. The reason it "just works" in the video, is because I use run without debugging every time I launch from VS. So if you simply want to follow the examples in the videos, all you need to do is run without debugging.
I started using WinDbg/SOS on CLR2 and x86. Launching a x86 .NET process from VS back then would trigger the error, so I made a habit of just launching without debugging.
However, as you have discovered there are scenarios where you can actually attach to a process that is being debugged by VS. I can reproduce the scenarios you describe, but I can also attach to a x64, .NET 2 process started with debugging from VS2008, but I cannot attach to the same process if the platform is set to x86.
Apparently there are subtle differences that I haven't been aware of, and it doesn't seem to be related exclusively to the .NET version, as I can attach to a x64 .NET2 process even if it is under the control of the VS debugger.
I'll update my answer if I find additional details.
I am writing a C# program that interface with COM object through COM interop.
I have a third-party program that register itself as the COM server when I execute the Application. This works fine in 32-bit Windows Vista and I can interface with the interop just fine. (The reference show up in "COM" tab from Visual Studio when you click "Add Reference")
However, the reference does not show up in "COM" tab on my 64-bit Windows 7 machine after I execute the application. Any thoughts, why would this happen? I actually tried using regsvr32.exe to register the application manually but it didn't work either (error message saying "entry-point DllRegisterServer was not found)
You are not going to be able to use it as long as it doesn't show up in the COM tab. The regsvr32.exe utility is for DLLs, this however sounds like an EXE. If it is a DLL then it needs to be registered with the 32-bit version of regsvr32.exe, the one in c:\windows\syswow64. If it is an EXE then the normal way to get it to register itself is by running it with the /regserver command line option.
Mumble.exe /RegServer
Additionally, if this is a DLL or an EXE for which you don't have a 64-bit proxy/stub then you'll have to force your app to run in 32-bit mode. Project + Properties, Build tab, Platform Target = x86.
If all else fails, you really do need support from the vendor of this program. Surely they'll have an update available that is verified to work properly on 64-bit operating systems. If they are no longer around, running this in a virtual machine is always a possibility.
If it is a managed dll then you might try using RegAsm
REGASM AssemblyName.dll /tlb:AssemblyName.tlb
You may find this helpful as I needed to recompiled and build 64 bit proxy stub for the COM server from C++ myself and it kept failing when trying to register the server using /regserver. Here is and thread from miscrosoft that helped me resolved this issue. Basically you need to use this instead /RegServerPerUser, but go through the thread if you get into this situation after the answers from above.
http://social.msdn.microsoft.com/Forums/en/vcprerelease/thread/11f01ceb-52a4-438f-b7ef-727ce7a3e191