Sep 202011
 

Are you having trouble converting VB6 project to VB.net Visual Studio 2010. Well just to be frank you should have long back converted this VB6 project of yours to VB.net. VB6 is ancient and just because your code works doesn’t mean that you won’t migrate it to a newer platform. In my opinion let your customers use the VB6 project of yours while you in the background should have converted a copy of it to VB.net. Now you might say it’s too much work… well how about it now. ūüėČ

Just to be clear Visual Studio 2010 does NOT inherently support converting VB6 project to VB.net 2010. When I force a conversion (via project open dialog) I get the following error dialog…

VB6 to VB.net 2010 - Conversion Error

VB6 to VB.net 2010 – Conversion Error

Recently¬†Mr. X¬†asked me this question so I sent him an email with the steps on converting a VB6 project to VB.net Visual Studio 2010. So here are the steps (straight from the email I sent to the customer…)

  1. Make sure VB 6.0 with SP 6.0 installed on the machine.
  2. Make sure that all the referenced components (ActiveX dll, OCX) for the VB 6.0 application is available on the machine.
  3. Open the VB 6.0 project in VB 6.0 IDE and make sure that it opens fine. Build the project and make sure that the application executes without any errors.
  4. Run the Upgrade assessment tool on the visual basic 6 project:
    (Old one) http://www.microsoft.com/downloads/details.aspx?FamilyId=10C491A2-FC67-4509-BC10-60C5C039A272&displaylang=en
    (New one) http://www.artinsoft.com/visual-basic-upgrade-assessment-tool.aspx
  5. Keep a local copy of the VB 6.0 project
  6. There is no direct wizard conversion in Visual Studio 2010. You have to first use the conversion wizard available in Visual Studio 2005/2008 to convert to VB.net and then convert the same to Visual Studio 2010. As you don’t have Visual Studio 2008, you can download free version from following link.
    http://www.microsoft.com/visualstudio/en-us/products/2008-editions/express
  7. Once you are done with the conversion you can uninstall Visual Studio 2008 express edition.
  8. Also you can download a free guide which contains information about Upgrading Visual Basic 6.0 Applications to Visual Basic .NET and Visual Basic 2005 (Its bit old but it will give useful insights as and when you are migrating source code to .net).
    http://www.microsoft.com/downloads/details.aspx?FamilyId=7C3FE0A9-CBED-485F-BFD5-847FB68F785D&displaylang=en

A general note:

As per the upgrade guide, the effect of the changes and subtle differences in Visual Basic .NET is that, unlike previous versions of Visual Basic, most real-world projects cannot be upgraded 100 percent automatically. To understand why, consider that for a 100 percent upgrade there has to be a one-to-one correlation between every element of Visual Basic 6 and a corresponding element in Visual Basic .NET. Unfortunately, this correlation does not exist. The upgrade process is closer to 95 percent, meaning that the Visual Basic .NET Upgrade Wizard upgrades 95 percent of your application, and you modify 5 percent of the application to get it working. What does 5 percent mean? If it took you 100 days to write the original Visual Basic 6 application, you might expect to take 5 days to upgrade it. This number is not set in stone-some applications are easier to upgrade than others, and the experience of the person doing the upgrade is an important factor. To prepare yourself, make sure you familiarize yourself with Part IV of the upgrade guide. It discusses how to design your Visual Basic 6 applications to make the upgrade process much smoother.

Microsoft Visual Basic 6.0 Migration Resource Center
http://msdn.microsoft.com/hi-in/vbrun/ms788233(en-us).aspx

Mar 152011
 

Introduction

This blog entry deals with user mode dumps only. Kernel mode dump files is not dealt with here but should be quite similar.

Define dump file

It is the memory snapshot of a process. The dump file saves all information pertaining to a process. The information include, loaded modules/dlls, handles, executing threads and other stuffs. Optionally we can include heap information.

How to open a dump file?

Dump files can be opened in a debugger as you would normally open a process or attach to a process. All debuggers provide options for opening a dump file. Here is¬†the menu option in WinDbg which opens a dump file…

Open dump file option in windbg

Open dump file option in windbg

A similar but, kinda hidden, version of¬†open¬†dump file option¬†in Visual Studio, its not so visible unless you dig a bit. See below screenshot…

How to create a dump file?

A quick¬†option which is quite is limited is to use the task manager “Create Dump File” option. Which looks like…

Task manager create dump file option
Task manager create dump file option

With windbg use the .dump /ma D:\DumpFile.dmp command. With visual studio you can attach to a process and use Debug->Save dump as or while you are debugging use Debug->Save dump as.

Another tool that comes along with¬†“Debugging tools for windows”¬†is ADPlus,¬†a VBScript based tool,¬†which automates the process of creating a dump file. This tool works by using cdb.exe (console debugger) command line options. Very powerful. I’ll blog about¬†the tool¬†in another post.

Limitations of dump files

You cannot execute¬†the¬†dump file,¬†just like you would normally¬†do with a process,¬†or set breakpoints;¬†a dump is a ‘snapshot’ of a process at a particular point of time. So all stuff in memory up till that particular point of time will be available but not after that particular point of time. Also if you have a wrong dump file then you could end up wasting time, so in order to prevent such cases we have tools like ADPlus which when setup properly automates the process of capturing dumps.

Different kinds of dumps

  • Crash dump – automatically taken during a crash
  • Hang dump – automatically taken (using tools like ADPlus)
  • High CPU dump – automatically taken (using tools like ADPlus)

Dump file tips in windbg

  1. I normally execute the following command in WinDbg: !analyze -v. This command gives a summary of the stuff in dump file. So it shows you the stack of the thread in which the exception occurred.
  2. Also when you open¬†a dump file in WinDbg you’ll get a brief summary of the exception that occurred and also a view of the registers.
  3. If you have a hang dump or a high CPU dump you will love the following command: !analyze -hang. This shows us the name of the function which is eating up most of CPU time.
  4. You¬†will love the command !runaway which shows the excecution time¬†for each thread, so this way you can identify the thread that’s¬†taking most of CPU time.
  5. To know the type of dump file you are¬†working on¬†enter “||” into WinDbg. This command will tell you whether you are dealing with a full dump or a mini dump. A sample output on a dump of MsPaint.exe looks like…
    0 Full memory user mini dump: D:\MsPaint.dmp
  6. To know the name and id of the process for which this dump was made use the single pipe command “|”.¬†Sample output looks like…
    0 id: 11e4 examine name: C:\Windows\System32\mspaint.exe
  7. .ecxr gives you exception record along with registers display.
  8. .lastevent shows you the last exception that occurred.
  9. You can create a mini dump out of a full dump by executing a .dump filename command on the existing dump.
  10. To view last error status of all threads use !gle -all
  11. Its very important to have the correct pdb files. Public symbol path and downstream store path should be set in WinDbg or by using _NT_SYMBOL_PATH environment variable. This is how mine looks -> SRV*C:\DebugSymbols*http://msdl.microsoft.com/download/symbols
  12. Don’t forget you are doing “post mortem” debugging. The dead doesn’t walk and talk. ūüôā
  13. ~* kpn shows stack of all threads
  14. !locks displays locks held by threads
  15. !lmvm ModuleName display information about a module. !lmvm User32 display information about user32.dll.
    • lm sm display all modules loaded/unloaded in sorted order,¬†‘when’ the dump was taken.
    • lm or lmvi display all modules loaded/unloaded in their load/unload order
  16. dt command displays type information of a type passed in.
  17. dv command displays all local variables
  18. x to examine a symbol. For e.g. to see all symbols in kernel32 starting LoadLibrary use following command: x kernel32!LoadLibrary*. The output looks like…
    00000000`77906640 kernel32!LoadLibraryExWStub =
    00000000`778fe3b0 kernel32!LoadLibraryExAStub =
    00000000`77907058 kernel32!LoadLibraryExA =
    00000000`77906f80 kernel32!LoadLibraryW =
    00000000`77907070 kernel32!LoadLibraryA =
    00000000`77906634 kernel32!LoadLibraryExW = 

Conclusion

Have fun debugging dump files and help others too. Spread word about this article. If you’ve got comments let me know. ūüôā