title: Troubleshooting VB6 App Crash after XP to Win7 Upgrade
body: <p>I have a VB6 application that I provide support for.  This application works on both Windows XP and Windows 7.  Some users were migrated from Windows XP to Windows 7 using the User State Migration tool.  These users now receive a generic "Application has crashed" Windows error message when they open certain screens (forms) in the application.  My assumption is that there is a missing dll/ocx reference, but I'm having trouble tracking it down.</p>
  
  <p>I've tried many/varied troubleshooting techniques:</p>
  
  <ul>
  <li>Full uninstall and reinstall of my application</li>
  <li>Manually re-registering all dll's and ocx's that I know are used</li>
  <li>Running Process Monitor on a broken computer and a working computer to compare what dll's and ocx's are accessed.  The answer might be here but even after filtering out most of the background noise the amount of data is overwhelming.  At a minimum I reviewed all of the calls right before it crashes and all of the calls that were not successful.  All of the non-successful calls match between working and non-working.</li>
  <li>Installed the Windows Debugger Tools and captured a crash dump.  Analyzed the crash dump with DebugDiag.  DebugDiag says the exception is in msvbvm60.dll.  I tried building a PDB file for my exe and loading it in DebugDiag to get more detail about where the exception is occuring but DebugDiag doesn't want to accept the PDB (might be doing something wrong here, but it just seems to ignore it.  This same PDB file works fine when I do remote debugging, however.)</li>
  <li>I recompiled my VB6 program without any optimizations in PCode.  I've read online that sometimes building in PCode, while bad for performance, will tell you the real exception.</li>
  <li>Used the above created PDB file to remote debug the VB6 application.  The debugger says that the application crashes after the new window has been created, on a line that sets <code>MousePointer = vbHourGlass</code>... To me it seems unlikely that this is the real cause of the error.  There are at least 20 other locations in the program where this same line is called and all work fine.
  (<em>Forgot about this one</em>)</li>
  <li>Used Dependency Walker and profiled the application on both a working and non-working computer.  All errors found by dependency walker were the same between the two computers.  There were no additional dependencies found on a working computer, and all missing dependencies on the non-working computer were also missing on the working one.</li>
  </ul>
  
  <p>None of these actions changed my error message or showed me what the error is (unless it really is the mouse cursor issue)...  There are no entries in the Windows Event Log related to the app crash.</p>
  
  <p>The non-working and working computers all have the same base Windows 7 image, the only difference is whatever is being changed by USMT, which further convinces me that this is some kind of quirky configuration change or a missing dll/ocx or perhaps an unregistered dll/ocx.</p>
  
  <p>Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.</p>
  
  <p><strong>Update 1 - Response to questions</strong><br>
  @MarkHall  I have tried running it as admin, though not with UAC off.  The application runs fine on a Windows 7 box as a non-admin with full UAC.  Windows XP was 32-bit, Windows 7 is 64-bit, but again it works just fine on a like for like box where the user was not migrated from Windows XP.</p>
  
  <p>@Beaner It's possible that it stores settings somewhere that have been corrupted, but the remote debugging leads me to think that it's more likely something else since it seems to die on a step related to the UI, which then makes me think it's probably a missing dll/ocx reference.</p>
  
  <p>@Bob77 The application is installed into <code>Program Files (x86)</code>.  While many of the libraries do reside in the same folder, they are all registered.</p>