The situation might sound a bit weird but I have to play with what I have.
There's a Win2003 64-bit server OS and a legacy application written using Visual Studio 6. The app consists of two parts: ActiveX components written in VB6 and C++ code which uses them.
I need to debug the components' code. I installed Visual Studio 6 on the server and I'm able to step into the component's code. Then I got following situation:
C++ code works until it needs to instantiate component A.
We switch to VB6 and start debugging component's A VB6 code.
In the very beginning component A creates an instance of a class C exposed by component B. At this step VB6 debugger shows error message with title "OLEDB32.DLL" and following text:
"Failed to load resource DLL C:\Program Files (x86)\Common Files\System\Ole DB\OLEDB32R.DLL"
Additional information: The last step in initialization of the class C is opening an ADO connection to SQL server using OLEDB provider.
I'd appreciate any ideas on how resolve this problem.
Thanks in advance.
The VB6 debugger has a reputation for sometimes being a bit flaky, and I'm not sure it was ever supported on 64-bit operating systems.
There are some other options for debugging VB6.
You could try debugging the VB6 in the Visual C++ 6 debugger at the same time as the C++. Compile the VB6 into native code with symbols (create PDB files). Then you should be able to step from the C++ straight into the VB6 and still debug. I have done this before (not on 64-bit). Here's a Microsoft knowledgebase article on doing this with C++ 5 - I think it's much the same in C++ 6. Here's info on doing it with Visual C++ 2008 (!)
Or you could try running the program in Windbg, a free standalone debugger from Microsoft. Again compile your VB6 into native code with symbols (PDB files) and you will be able to debug your VB6 in Windbg. You should also be able to debug the C++ at the same time.
Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft VB guy with a brief introduction to Windbg.
MDAC registers ADO/OLEDB classes like this: %CommonProgramFiles%\System\Ole DB\sqloledb.dll
Check if your process environment is corrupted in some way. If you use restart manager (when your app crashes it is restarted) does not restore environment. We guard with something like this in Sub Main
If LenB(Environ$("CommonProgramFiles")) = 0 Then
Call SetEnvironmentVariable("CommonProgramFiles", pvGetSpecialFolder(ucsOdtProgramFilesCommon))
End If
If LenB(Environ$("CommonProgramFiles(x86)")) = 0 Then
Call SetEnvironmentVariable("CommonProgramFiles(x86)", pvGetSpecialFolder(ucsOdtProgramFilesCommon))
End If
Related
Trying to do this on Windows 10.
I have a VB6 folder and I'm trying to make a solution out of it.
Visual Studio succeeds in making a project, but when trying to compile it gives millions of errors (see image).
I've read conflicting info about VB6 support in Visual Studio.
On one hand it's written that Visual Basic is supported, but not VB6?
There also used to be a VB6 IDE, but I can not find a download for it.
Should I use Visual Studio 2008 or something?
What are my options?
Thank you.
When Microsoft today uses the abbreviation "VB", they usually mean "VB.NET", the successor of classic VB published by Microsoft in 2002. According to this source, the latest version of VB, called VB6, appeared in 1998, and 10 years later Microsoft dropped any support for VB6 and its IDE.
Unfortunately, VB.Net is not backwards compatible to VB6, it is a different programming language (though it has some properties which arguably make it easier to port VB6 to VB.Net than to other .Net languages like C#). You cannot compile VB6 programs directly with Visual Studio 2002 or later, you usually need the original VB6 IDE. That leaves you basically with two options:
Try to find a copy of the old VB6 IDE and compile the program with it (if you cannot get it from where you got the source code, according to the comments, you may have luck at Microsoft, when you have the right developer subscription level).
Port the VB6 application to VB.Net. For this, however, you should have some not-too-basic knowledge of both languages, know the differences and ideally have an environment where you can test the original application against the ported one. I did this by myself in the past for some applications, so I know it can be less effort than recreating an application completely from scratch. However, this depends a lot on the specific application, how large and complex it is, how large the UI parts are and which kind of 3rd party components were involved. To be honest, if the application is not trivial, you should have a VB6 IDE for this approach, too.
Note also when your old VB6 code uses 32-bit third party OCX/ActiveX components, for porting it to VB.Net I would recommend to use VS2019 or an earlier version, not VS2022. The current Winforms Designer of VS2022 is not compatible with 32 bit OCX components any more, and it is unclear if MS will ever publish a version which will be.
I have a dump file generated using Windows Task Manager. The process it is created for is a Borland (now Embarcadero) C++ application.
Is it possible to use such a file for Borland applications?
If yes, then how?
As you have created a dump of an application, that's called a user mode crash dump. Such a dump is typically analyzed in Microsoft Visual Studio, Microsoft WinDbg or DebugDiag.
The debuggers are available for free. WinDbg is part of the Debugging Tools for Windows and Visual Studio 2015 is provided as a Community Edition. For WinDbg, install both versions, x64 and x86 so that you can debug any kind of dump. DebugDiag has a simple UI and doesn't allow doing manual analysis.
If you have taken the default Task Manager of a 64 bit OS to take a dump of a 32 bit application, you might be unlucky though. Try getting a 32 bit dump for a 32 bit application, that's better if you're new to debugging. This answer shows the various ways of getting good dumps. This will also be fine for you, not only for .NET.
Analyzing the dump in DebugDiag
Open the dump in DebugDiag
Select a type of analysis
Run
Read the HTML report it generated
Analyzing the dump in Visual Studio
Open the dump in Visual Studio
Press the green play button
Look at the message to see the exception
Look at the call stack
...
Visual Studio has many commands and possibilities, but explaining them all here is too broad. If you have a more specific idea of what you want to know about your dump, ask a new question.
Analyzing the dump in WinDbg
Open the crash dump in WinDbg (use correct bitness).
Set up the symbols
Start analyzing, e.g.
~ to get a list of threads, ~xs to select a thread (where x is the thread number)
k to get a call stack
.exr -1 to get info about an exception
!analyze -v to perform an automatic analysis
...
Learning WinDbg is a hard task, since most things are done via cryptic commands and not via UI, but it can do almost everything.
For specific problems, ask questions using the windbg tag.
Normally I work with Visual Studio and also debug with visual studio. But we have virtual machines in another network there is Visual Studio not installed. And I can not remote debug. To install every time Visual Studio is in my eyes a overhead.
So I look for a small debugger for managed (c#) code that I can copy into the virtual machines to set breakpoints, step through the source code, see exceptions.
Knows someone a small debugger for managed code?
There is mdbg - it is harder to use (evaluator has a strange syntax) but on the other hand it is super-lightweight. You may get it from Windows 7 SDK (I don't know why they remove it from Win 8 SDK): c:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\ (x64 for 64-bit - you will need mdbg.exe and mdbgcore.dll) or compile it by yourself using source code from here: http://www.microsoft.com/en-us/download/details.aspx?id=2282. Make sure that you choose the correct bitness. I used it with success in production environments (also for .NET4.5 applications) and even created 2 extensions for it - maybe you will find them useful:
http://lowleveldesign.wordpress.com/2012/02/27/mdbg-watch-trace-extension/
http://lowleveldesign.wordpress.com/2013/12/28/injecting-code-into-net-applications/
If mdbg is not enough and you need to get deeper (analyze GC Heap, .NET iternals etc.) you probably will need to learn windbg (it's also xcopy deployed and you can get it from Windows Debugging Toolkit).
We have a .NET application using a lot of legacy components written in VB6. We were able to debug the VB6 code using native code debugger and generated pdb files in Visual Studio 2010. After upgrading to the VS 2012 (including Update 2) we cannot do this.
The module window shows following message:
Binary was not built with debug information.
You can also find following message in the output window:
Module was built without symbols.
When I try to load symbols manually, I get following message:
A matching symbol file was not found in this folder.
Debugging the very same dll or exe from VS 2010 works fine.
Is there any option to enable it?
I found a solution that works on my machine (per Microsoft's comments on ScottG's paid support request - thanks, Scott). Apparently Visual Studio's default debugger after 2010 doesn't handle VB6 DLLs, but there's a checkbox to use the old debug engine, which does:
I didn't need to enable Native Edit and Continue.
I have finally found how to enable debugging VB6 components using Visual Studio 2012. In short, you have to enable the old pdb format first by setting Options | Debugging | Edit and Continue | Enable native Edit and Continue and then you can attach to the dllhost.exe as usually.
In VS 2015 Tools->Options->Debugging->General, select 'Use Native Compatibility Mode'. It sucks that I still need to debug VB6, but I am thankful that I am still able to.
it seems that VS 2012 use msdia110.dll to decode symbol files, there's a DIA SDK sample in VS folder, you can test whether it can parse those VB pdb files. if it can't, i guess the new version DIA does not support old version pdb any more.
Using VB6, I have created an Outlook plugin, that has a property page. The property page is an OCX control.
When I compile the project to an OCX file, and then run OUTLOOK, things work fine: I am able to see my OCX as a tab in the Outlook options.
However, when I try to debug by running the OCX in VB6 I get an error. My debugging is started like this:
1) Debug options set to Wait for components to be created"
2) F5-RUN project in VB6.
3) Start Outlook.
4) Get the error: "Cannot display "MyOcx" page. This page will remain visible, but is not available. An OLE registration error occurred. The program is not correctly installed. Run Setup again for the program"
I suspect this is because, when debugging, the OCX is being created out-of-proc and Outlook doesn't like that.
Is there a good technique to use the VB6 debugger on the OCX in this scenario?
The VB6 debugger is sometimes flaky when debugging DLLs or OCXs.
You could try Windbg, a free standalone debugger from Microsoft. Compile your VB6 OCX into native code with no optimisation and "create symbolic debug info" (i.e. create PDB files), and you will be able to debug your OCX in-process in Outlook. Here's a 2006 blog post by a Microsoft guy about using Windbg with VB6, and 2004 blog post by another Microsoft guy with a brief introduction to Windbg.
You could also use the Visual Studio 2008 debugger with VB6 and PDB files, e.g. with Visual C++ Express Edition (which is free). EDIT see Kris's answer for more details.
EDIT: Both Windbg and Visual Studio expect the source code to be in exactly the same path on the debug machine as it was on the build machine when the OCX was built. The easiest way is to build and debug on the same machine. Otherwise you might need to fiddle with SUBST to create virtual drives - or I'm told the serious way is to use a Symbol Server.
(Les serious) you could do without those newfangled interactive debuggers, just log to a file, or with DebugMessage calls from your VB6.
The only way you are really going to be able to Debug this is In Process as MarkJ said. Using the free Visual Studio 2008 C++ Express Edition (or even better, Visual Studio 2008 Professional if you have it, and it is available for a 90 day trial) and a PDB.
To make sure you are creating the PDB, go into Visual Basic, check the P)roject / P)roperties and click on the Compile tag. Make sure "Create Symbolic Debug Info" is checked.
Next start up Outlook, and attach to that process from Visual Studio (T)ools / Attach To Process. Make sure your Ocx is shown in the modules window, and then load the PDB (right click on the Ocx in the modules window). You will probably have to add the source code in the Solution Properties (for more details on how to do that, read this post).
It's a bit of a pain in the butt the first time, but once you can do it, it becomes pretty easy, and is far easier than trying to determine what is going on from a log.
I don't have much idea on the OCX.
However, you can use a tool which was part of visual studio named something like "activex control test tool".
As far as I know (based on my understanding of documentation), OCX is created in-proc.