vb6 program runs in win 10, both IDE and .exe.
program compiles on both systems
program fails on win 11 but doesn't identify which library is at fault. dependancy checker is no help. error occurs immediately upon start so debug trapping reveals nothing.
Related
I have an executable compiled by MSVS2013 on Windows 7 SP1 32 bit with C runtime statically linked and platform toolset "Visual Studio 2013 - Windows XP (v120_xp)"
It runs perfectly on Win7 (see attached screenshot of Dependency Walker profiling).
It fails to run on WinXP:
Here is the profile log:
Starting profile on 12/9/2014 at 2:55:03 AM
Operating System: Microsoft Windows XP Professional (32-bit), version 5.01.2600 Service Pack 3
Program Executable: c:\temp\OCTOPUS.EXE
Program Arguments:
Starting Directory: C:\Temp\
Search Path: C:\Program Files\ActiveState Komodo Edit 8\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\MATLAB\R2009b\runtime\win32;C:\Program Files\MATLAB\R2009b\bin;C:\VisaPoint\sbperl\perl\bin
Options Selected:
Simulate ShellExecute by inserting any App Paths directories into the PATH environment variable.
Log DllMain calls for process attach and process detach messages.
Log DllMain calls for all other messages, including thread attach and thread detach.
Hook the process to gather more detailed dependency information.
Log LoadLibrary function calls.
Log GetProcAddress function calls.
Log thread information.
Use simple thread numbers instead of actual thread IDs.
Log first chance exceptions.
Log debug output messages.
Use full paths when logging file names.
Log a time stamp with each line of log.
Automatically open and profile child processes.
--------------------------------------------------------------------------------
00:00:00.000: Failure starting the process. %1 is not a valid Win32 application (193).
[1]: http://i.stack.imgur.com/m82n6.png
[2]: http://i.stack.imgur.com/6Yr37.png
Modern versions of Visual Studio, starting with VS2012, use linker settings that marks the executable image compatible with the current generation of Windows. Version 6, started with Vista. XP and Server2003 were in the previous generation, version 5.
You can still build programs that run on XP with VS2013. But you have to make a setting change. Right-click the project, Properties, General. Change the Platform Toolset setting to v120_xp.
There are a few consequences, your program gets built with an old version of the Windows SDK. V7.1, the last one that was still compatible with XP. The C runtime library makes a bunch of operating system calls that are only available in generation 6. It will stumble along without them, affecting relatively minor details related to threading and culture. This is the kind of FUD that ought to remind you that it might not be the best idea to still promise support for such an ancient operating system. Make sure you keep a running version of XP around so you can properly test and repro. And keep in mind that you can't install VS on it anymore so if you do get a support call from an XP user then you tend to get a fairly heavy migraine.
Ok, just forgot to set SUBSYSTEM in Linker options.
Here is a link with explanations:
https://software.intel.com/en-us/articles/linking-applications-using-visual-studio-2012-to-run-on-windows-xp
Ive got an issue using RFT with VB6 on Win7 (32,64) bit. This isnt is not present on Windows XP.
I am unable to highlight objects, or call verification points as the VB6 application crashes with a stackhash error. I have done weeks of research and have tried various things(DEP, Compatibility mode, clean boots etc) but am thus far unable to isolate the issue.
It seems that certain properties, these can vary, are not available once the program has been compiled. Running the application through VB6 IDE in debug mode does not result in a crash. Once compiled though, the crash occurs constantly.
I have used Windbg to debug the error to see what happens, and can see that there is a call to unallocated memory, resulting in heap corruption. What causes this? Is there anyway around this?
Any help would be appreciated :)
I have an application written in Delphi XE3 (Originally Delphi 7) with a MySQL database. It was running on 5 computers on a network. Two of the computers were on windows 7 while 3 were still windows XP. The client recently upgraded the 3 windows XP computers to windows 7 x64 (3 brand-new identical machines). The program is running fine on one of the new computers but on the other 2 I get the error message "A problem caused the program to stop working. Windows will close the program and notify you if a solution is available". The program seems to crash at the end of the FormActivate procedure after it had verified the password and connected to the database. The MySQL server is up and running. I can access the database on the problem machines locally and remotely successfully.
I have searched the Internet and some websites suggest that this error is a protective mechanism from Windows triggered by a thread to system files, indefinite loops or memory problems – none of which are applicable to my program.
I have since reformatted the 2 problem computers and reinstalled Windows 7 again but it did not solve the problem.
The DependencyWalker output on both problem and working machines (and on my development machine) are identical :
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
With regard to different CPU types - in all instances the application is x86 and the rest of the modules are x64. This could be a 32-bit-64-bit problem but the program is running on all the machines except for 2 problem machines.
The Windows Event Viewer reports the following error:
Faulting application name: February_2014.exe, version: 1.0.0.0, time stamp: 0x52fa3b19
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18229, time stamp: 0x51fb1116
Exception code: 0x0eedfade
Fault offset: 0x0000c41f
Faulting process id: 0x1510
Faulting application start time: 0x01cf28a57840f88d
Faulting application path: C:\dgpa dgr\February_2014.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: bd26ca27-9498-11e3-9479-7c050710b013
I have searched the Internet (and Stackoverflow) for KERNELBASE.dll but could not find anything useful.
I have asked for help on Windows Technet without success
http://social.technet.microsoft.com/Forums/windows/en-US/ef52b2e1-237d-436f-952f-7cdecdb48337/a-problem-caused-the-program-to-stop-working-windows-will-close-the-program-and-notify-you-if-a?forum=w7itprogeneral
The program is running without the hitch on my Windows 7 x64 development machine so I cannot replicate the problem/error that I am experiencing at my client. Has anybody had a similar problem? Any suggestions for the cause/trigger of the Error and how to solve it?
UPDATE
I got the following report from madExcept but I have no idea what it means
If you include a ClientDataSet in your application you need to deploy midas.dll with your application, or you have to manually add the MidasLib unit to your project's uses clause (for example)
program Project1;
uses
MidasLib,
Forms,
Unit1 in 'Unit1.pas' {Form1};
For a detailed explanation see the article of Cary Jensen on the topic.
The screenshot from madExcept is telling you that your program is raising an exception at startup, before you call Application.Run. The root of the exception is in the call to Application.CreateForm made in your project file.
The top-level exception handler is contained in the main application message loop that is implemented in Application.Run. Because you have not yet started the main application message loop, there is no exception handler.
This means that the exception leaks out of your application and the system has to handle it as best it can.
I don't know how to fix your specific problem, but the madExcept diagnostics tell you where to start looking. Ideally you would like to be able to debug this scenario in the IDE. Once you can do that it will be much easier to track down.
Fundamentally, if you leak exceptions out of your startup code, you will encounter such error dialogs.
I know of a few things that could be potential sources of the issue. First is the space (blank) in the path name where the application is running. Trying moving app to a subdirectory with no spaces in the path name. Second try running in Admin mode if you are not already. The answer that references "midas.dll" is another one. With the additional warning that Delphi used to install a copy of midas.dll in the Windows\System32 directory. Make sure that your version of midas.dll came with the version of Delphi you wrote the code in (and make sure that there isn't another older copy being found before the one you intended. Depends.exe can help show the path to the dll it loaded. Also have you tried running the app using "XP Compatibility"? Does the issue go away? Also have problems with DB components on a DataModule form in Delphi before. If you have a DB component with a AutoConenct on (or Streamed connection), it can cause unusual errors. Best to leave it disconnected and connect it in your source code at runtime. Last thing to try, look at the Windows services and see if the Performance Logs are running prior to launching your app. A weird one, but I've seen it.
I'm working with a DirectX 11 program on Windows 8 for which I Think there is a problem with the vertex shader. I tried to start DirectX diagnostic mode ([Alt]+[F5]) and while the program will normally run without throwing an exception if diagnostic mode is turned on it will always crash at the call to "CreateSwapChainForHwnd" with the following error message
Unhandled exception at 0x0097C004 in MyApplication.exe: 0xC0000096:
Privileged instruction.
Does DirectX debugging simply not work for Windows Storeapplications? It seems to work fine in specific Win32 application scenarios, but I seem to be encountering many scenarios where it doesn't work.
Update:
Among other things I installed the DirectX debugging symbols and got a marginally more detailed message.
Unhandled exception at 0x000007FDED063589 (dxgi.dll) in
MyApplication.exe: 0xC0000005: Access violation reading location
0x0000000000000000.
So it looks to be a null reference exception from the code on Microsoft's end.
I think your problem is that the debugger doesn't like CreateSwapChainForHwnd(), as this other guy found out: Requirements for target application for Visual Studio 11's Graphics Debugger
My code calls D3D11CreateDevice() followed by IDXGIFactory::CreateSwapChain() and the debugger works for desktop win32 apps, so try that.
What are the specific Windows Store application scenarios that you got it to work in? I have the exact opposite problem - I cant get Alt-F5 debugger to work at all for windows store apps, but it works for desktop win32 apps.
I am attempting to debug an error while loading my x64 application and am receiving an "MyAPP has stopped working" immediately before the first line of code in main().
What I am wondering is why when I use the debugger in Visual Studio 2010 (myapp.vshost.exe process) I can step through the code just fine and everything appears to run.
Figured it out - ansering my own question for future reference.
The main application was being profiled by Application Verifier (x64) which was causing a stack overflow. As applications under test is set in the registry, I had completely forgotten that this was still set in the list of processes to test. Since the vshost process is using it's own .exe it was not being profiled... no crash!