I am creating a BHO using helloworld sample. Building Browser Helper Objects with Visual Studio 2005
the BHO is not getting loaded, and i am not able to hit the breakpoints in SetSite function.
Please let me know what additional settings are required to register BHO and subsequently debug it.
I am using IE9, VS2008.
Thank you very much
This is because the debugger is not attaching to the right IE9 process. To work around this you need to dictate IE9 to use a single process for all tabs. This can be done by setting the registry value: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\TabProcGrowth = 0
Hope this helps.
Are you certain that you've registered it? Assuming that you've accurately implemented the example in the link above (particularly the section about using the correct CLSID in the .rgs file), try from an elevated/admin CMD window:
regsrv32 /s mybho.dll
This will register the COM objects within the DLL, as well as registering it with Internet Explorer as a BHO
Additionally, with IE9 you'll need to make sure it's enabled in the Addons manager (tools/manage addons)
I had the same issue. I was using 64 bit IE9 but I changed the debugger to use 32 bit and it works for me now.
In VS 2008 go to the menu:
Project -> Project Name Properties -> Configuration Properties -> Debugging -> Command
C:\Program Files (x86)\Internet Explorer\iexplore.exe
I was using 64 bit before:
C:\Program Files\Internet Explorer\iexplore.exe
Also use a local file to avoid issues with protected mode:
Command Arguments:
path to some local html file
Good Luck...
Are you running in protected mode? If yes , then the breakpoint in SetSite will never be hit.
Refer http://msdn.microsoft.com/en-us/library/bb250462.aspx to know more about protected mode.
Also did you try registering the BHO using regasm ?
Related
I saw some code on codeproject like this and this. but both are not compatible with the new security policy of internet explorer add-ons, when i insert then on registry they show up on the IE add-ons list, but with the "incompatible" status. Some can show me a working example for IE11 add-on? or can show me what i need to change? (i already disabled the security mode, but even with that i couldn't make it work) there is something to do with EPM (Enhanced Protected Mode)?
Have you used regsvr32.exe to register your BHO? I have IE 11 and used your second link as a boilerplate project, and I have no problems getting the dll to work in IE (besides having problems with working with the IE api - but that's not relevant).
What I did to get the BHO to work:
Have IE 11
Have Visual Studio 2015
Download the project from codeproject, doubleclick the solution
Convert it to the new format and download the dependencies (VS asked me to convert it, and I didn't have VisualC++ for Visual Studio or something)
Build it in release (I haven't actually tried debug)
Execute regsvr32.exe in an admin command prompt
Start IE and enable the BHO when IE asks you to
That's basically everything I did, and I didn't get an error on the way.
EDIT: Oops, sorry for necroing this. That was not my intention.
I feel like this is a stupid question, but I can't seem to figure out the answer. I've currently got a C++ application that's loading & utilizing a DLL (I compiled both the application & the DLL with VS 2010). I'm positive it's using the DLL, because a) if I rename the DLL, I get a not found exception, and b) it's displaying output that only comes from (and I can change it to see the output change) inside the DLL.
My problem is that in Visual Studio's Modules window while debugging, the DLL does not appear to be loaded. Because of this, obviously its got no symbols and I can't set breakpoints... But this doesn't make any sense to me as it's clearly using the DLL.
I've seen several other similar questions, and the answer has generally been too look at whether the code is native, managed, or mixed, and set the "Attach to Process" field accordingly. I've tried all the options there, and made sure my Debugger Type is set to "Mixed" (though I've tried it with Native & Managed as well, just to verify none of these solve the issue).
Does anyone have any suggestions?
Thanks in advance!
This happened to me and I found the project->properties->Debug page and clicked the box to Enable native code debugging. I was doing a C# project accessing a C++ / native dll
budward
I have some ideas:
check output windows it the DLL symbols are missing.
Make sure dllname.pdb file exist beside the DLL
make sure visual studio solution has two projects (EXE,DLL) projects
switch to DEBUG mode instead of RELEASE mode.
run process explorer (download it from MS) and check the path of the DLL that is bonded to the EXE in runtime.
Finally the ultimate solution:
Open Process Explorer and search for your DLL name.
Find which EXE is using it.
Goto VS and attach your debugger to that EXE.
I hope any of those fix your issue
I am using msado21.tlh to append record in recordset. But the Append function causes runtime check failure#0 error. I searched about the error and came to know its related to calling convention. I am not able to solve this error. Please help.
I am using Visual studio 2012, OS is windows server 2008 R2 SP1, 64 bit machine.
I am having a web site application which uses a C++ application which is a window service(32bit). This C++ application uses msado21.tlb. The calling convention set in project properties is __cdecl(/Gd) and the path for msado21 is set to C:\program files\common files\system\ado. Also, inside IIS manager the flag for enabling 32 bit process in AppPool is set to true.
But if I use msado21.tlb from C:\program files(x86)\common files\system\ado then everything works fine. I am unable to understand what is the root cause of this problem and how to resolve it?
Please provide some guidance.
Thanks
Well, I am facing a strange problem. I have developed a sample MFC ribbon application on my machine - Windows 7 , with Visual Studio 2008. When I copy paste the .exe onto my laptop and run the app , I don't see the ribbon menu (in fact the app has not menu now) .
I have tried looking up the .dll that load in each case(on my work machine and laptop) using process monitor but I am unable to locate what I might be missing. Any help will be greatly appreciated.
Edit 1 -
Ok, So thanks for your responses. Some progress has been made with this issue
I changed my IDE to VS 2010. The ribbon was coded manually and I figured out if I could add it as a resource maybe the problem would be solved. VS 2008 did not have the option of adding a ribbon as a resource.
I installed the VS 2010 Service Pack Redistributable X86/X64 depending on whether the machine is 32 or 64 bit.
I built a new "ribbontest.exe" app from VS 2010 and deployed it on other machines on which I would test my actual app. The ribbon for "ribbontest.exe" loads without any problems.
When I deploy my app and run it, first the old menubar loads for a sec or two, then the ribbon flashes and disappears.
A little history of the app I am referring to -
Initially my application had the menubar view. I followed this article http://www.codeguru.com/cpp/cpp/cpp_mfc/tutorials/article.php/c14929/MFC-Feature-Pack-An-Introduction.htm to accommodate a ribbon.
Any suggestions?
Most likely there's a conflict in the settings 'paths'. In your InitInstance() handler, you've got a statement like this:
// Standard initialization
// If you are not using these features and wish to reduce the size
// of your final executable, you should remove from the following
// the specific initialization routines you do not need
// Change the registry key under which our settings are stored
SetRegistryKey(_T("yourappname"));
If you haven't changed that name yet, do it. If you did, open regedit.exe on your target machine and remove the whole key under HKCU\Software\yourappname and then try again.
MFC stores user customizations of Ribbons/Menus/... under that key. But if you changed your app those settings don't necessarily match anymore and you can end up with stuff not showing correctly or not at all.
Make sure you download and install the Visual C++ Redistributable Runtime on your destination machine: http://www.microsoft.com/en-us/download/details.aspx?id=29
Or, something like it. Make sure you have architecture (x86/x64) correct and make sure it matches with the service pack version you compile with.
Joe is right: you need redistributable.
Joe is right: you cannot run 64-bit program on 32-bit machine.
All of the above would be indicated by the system (missing DLL, configuration incorrect, or 64/32 bit discrepancy)
Joe is right: your application must be built for specific set of minimum Windows version and service pack.
In addition to Joe’s post you must run release build not debug build.
If all of those requirements are met and you still have this problem, try linking MFC statically and see if problem persists.
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.