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.
Related
After SSD failure, reinstalled Win10 and vb6. Application uses Far Point 2.5 spread sheet component, ss32x25.ocx. regsrv32 loads but call to DllRegisterServer fails w/code 0x80040201. Project Components display from IDE shows Far Point 2.5 in use, but project.vdp does not contain object reference "Object={B02F3647-766B-11CE-AF28-C3A2FBE76A13}#2.5#0; ss32x25.ocx".
When run in IDE, registry error above shows. Has also said "not registerable as an ActiveX Component".
Second machine, no failures, properly runs same app and displays objects being used. I have all support files for ss32x25.ocx.
Note that VB6 no longer installs cleanly due to Win10 changes; both machines have experienced that wild ride before ~ 3 years ago. This one looks just about ready to take off. Just need to fix registration.
I was wrong in my statement that object reference "Object={B02F3647-766B-11CE-AF28-C3A2FBE76A13}#2.5#0; ss32x25.ocx" was missing in the project.vbp file. It was 2 pages down the list.
This all started in re-loading visual studio. Somehow I learned loading only VB as admin were the keys to success. Reloading Far Point occurred somewhere in the process. But it wasn't a clean register for it or a home grown dll defining a batch of structures. regsvr32 loaded but failed some specific call.
Registration had to be the problem. I explored regedit and found Far Point looked good but my dll had gotten nowhere. Noting I still had to run the IDE as admin, I tried regsvr32 as admin for both items. Both were successful!
And, I don't have to run the IDE as admin!
*THIS HAS BEEN EDITED, SEE BOTTOM. I CHANGED THE TITLE TO BETTER REFLECT THE PROBLEM.**
I have an old vb6 application that I put on a windows 2016 server and been having issues with dependency files. I ran process monitor and started putting the dll files in the locations where it is looking at, most of them have cleared up.
I'm getting one that I cant find on the old win 2000 box or anywhere else: wow64log.dll
Where can I can get this file? I attached pics of proc mon and the list of dependencies that the app is requiring. any direction would be appreciated. third pic is the actual error when trying to open the app. edit added the dependency walker screen shot
EDIT***
so I have narrowed down the issue and it boils down to an ADO connection. I cant seem to connect on windows server 2016 using ADO. I suspect it has something to do with the connection string, but what baffles me is why does this work on a win 10,1803 box and not on windows server 2016 1607 ?
this is basically my issue - https://social.msdn.microsoft.com/Forums/SECURITY/en-US/f1eee40b-6ab2-445f-a361-ae965439273a/run-time-error-214746725980004005-for-using-adodbconnection?forum=isvvba
I suspect that this is not an actual error in the runtime of your program, If you are only looking at Procmon, be aware that it shows a lot of stuff and sometimes not all the "errors" there are really relevant. For instance, it will often show how Windows functions look in a long list of search paths, each failing in turn, before that actual location of a DLL is detected.
In this case, it seems most likely that a missing wow64log.dll is harmless and apparently, totally normal.
"WoW64" is the Windows subsystem which runs 32 bit programs inside the 64 bit operating system. ("WoW" stands for "Windows-on-Windows".)
According to the reference WoW64 Internals describing how this subsystem is initialized:
wow64!ProcessInit
...
It … tries to load the wow64log.dll from the constructed system
directory. Note that this DLL is never present in any released
Windows installation (it’s probably used internally by Microsoft for
debugging of the WoW64 subsystem). Therefore, load of this DLL will
normally fail. This isn’t problem, though, because no critical
functionality of the WoW64 subsystem depends on it.
Although that article is talking about the ARM64 architecture (which AFAIK is not what most PCs would be using) it sounds like much of the WoW64 system is similar to normal PCs.
Please forgive my ignorance, but I am not familiar with Visual Studio or Windows DLLs & services. Normally I work in an embedded environment but somehow (just lucky I guess) I got selected to troubleshoot a crash that occurred in one of our Windows services, well actually in MSVCR80.DLL, but which I must presume was caused by our service (Windows event log below)
Faulting application name: MySrvc.exe, version: 0.0.0.0, time stamp: 0x4fee02e5
Faulting module name: MSVCR80.dll, version: 8.0.50727.4940, time stamp: 0x4ca2b271
Exception code: 0xc000000d
Fault offset: 0x00008aa0
The trouble I'm having is that when I attach to the process and then get it to crash, the debugger breaks and then the call stack only has some calls within mscvr80.dll and ntdll.dll and that's it, no calls from our service into those libraries. My guess is that the library is multi-threaded and the stack I'm seeing is just one of it's threads. But when the VS debugger breaks, does it not pause all threads? And is there a way to examine the call stacks of the other threads? Or am I completely off base here?
Again, please forgive my ignorance in this area. Any advice or direction you can offer will be greatly appreciated. Thanks in advance!
-H
There are two possibilities:
You're looking at the wrong thread, as you say, in which case you can switch to the right one using the Threads window, via Debug / Windows / Threads. (But that's unlikely - when a thread crashes, VS will show you that thread.)
You need to load the symbols for the system DLLs - Visual Studio sometimes can't follow stack traces without the symbols. Go to Tools / Options / Debugging / Symbols and make sure you're obtaining symbols from Microsoft.
I have a completely random error popping up on a particular piece of software out in the field. The application is a game written in VB6 and is running on Windows 7 64-bit. Every once in a while, the app crashes, with a generic "program.exe has stopped responding" message box. This game can run fine for days on end until this message appears, or within a matter of hours. No exception is being thrown.
We run this app in Windows 2000 compatibility mode (this was its original OS), with visual themes disabled, and as an administrator. The app itself is purposely simple in terms of using external components and API calls.
References:
Visual Basic for Applications
Visual Basic runtime objects and procedures
Visual Basic objects and procedures
OLE Automation
Microsoft DAO 3.51 Object Library
Microsoft Data Formatting Object Library
Components:
Microsoft Comm Control 6.0
Microsoft Windows Common Controls 6.0 (SP6)
Resizer XT
As you can see, these are pretty straightforward, Microsoft-standard tools, for the most part. The database components exist to interact with an Access database used for bookkeeping, and the Resizer XT was inserted to move this game more easily from its original 800x600 resolution to 1920x1080.
There is no networking enabled on the kiosks; no network drivers, and hence no connections to remote databases. Everything is encapsulated in a single box.
In the Windows Application event log, when this happens, there is an Event ID 1000 faulting a seemingly random module -- so far, either ntdll.dll or lpk.dll. In terms of API calls, I don't see any from ntdll.dll. We are using kernel32, user32, and winmm, for various file system and sound functions. I can't reproduce as it is completely random, so I don't even know where to start troubleshooting. Any ideas?
EDIT: A little more info. I've tried several different versions of Dependency Walker, at the suggestion of some other developers, and the latest version shows that I am missing IESHIMS.dll and GRPSVC.dll (these two seems to be well-known bugs in Depends.exe), and that I have missing symbols in COMCTRL32.dll and IEFRAME.dll. Any clues there?
The message from the application event log isn't that useful - what you need is a post mortem process dump from your process - so you can see where in your code things started going wrong.
Every time I've seen one of these problems it generally comes down to a bad API parameter rather than something more exotic, this may be caused by bad data coming in, but usually it's a good ol fashioned bug that causes the problem.
As you've probably figured already this isn't going to be easy to debug; ideally you'd have a repeatable failure case to debug, instead of relying on capturing dump files from a remote machine, but until you can make it repeatable remote dumps are the only way forwards.
Dr Watson used to do this, but is no longer shipped, so the alternatives are:
How to use the Userdump.exe tool to create a dump file
Sysinternals ProcDump
Collecting User-Mode dumps
What you need to get is a minidump, these contain the important parts of the process space, excluding standard modules (e.g. Kernel32.dll) - and replacing the dump with a version number.
There are instructions for Automatically Capturing a Dump When a Process Crashes - which uses cdb.exe shipped with the debugging tools, however the crucial item is the registry key \\HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
You can change your code to add better error handling - especially useful if you can narrow down the cause to a few procedures and use the techniques described in Using symbolic debug information to locate a program crash. to directly process the map files.
Once you've got a minidump and the symbol files WinDbg is the tool of choice for digging into these dumps - however it can be a bit of a voyage to discover what the cause is.
The only other thing I'd consider, and this depends on your application structure, is to attempt to capture all input events for replay.
Another option is to find a copy of VMWare 7.1 which has replay debugging and use that as the first step in capturing a reproducible set of steps.
Right click your executable object and let it be WINXP compatible pending
when you discover source of the problem to finally solve it
We are working on vs 2010 windows 7, 32 bit and the project is running under target framework 3.5.
Now we are implementing credit card process in the website project in signup page.
It's running fine when running from VS IDE, but after publishing to the local IIS when clicked on signup button, it's showing this error:
An unhandled win32 exception occured in w3wp.exe The Just-In-Time
debugger was launched without necessary security permissions. To debug
this proces, the JIT debugger must be run as an administrator. Would
you like to debug the proces?
In Application error log im seeing this
Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: ntdll.dll, version: 6.1.7600.16385, time stamp: 0x4a5bdadb
Exception code: 0xc0000374
Fault offset: 0x000c283b
Faulting process id: 0x3e4
Faulting application start time: 0x01cca60dbfd76d52
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 126cc4b9-1201-11e1-b3db-003018a9eb5e
It was working fine three days ago from IIS. I do not understand what change caused this issue.
Edited
if i select debug this process.. app working fine. The real problem is after publishing same build to the live server(win 2k8, 64 bit), in sign up page i used captcha even i entered correct code its saying you are not entered correct code. which is working fine in local system.
I don't know if your problem had the same cause, but I got this error when trying to debug my app (just pressing F5).
We got crazy trying to figure why the w3wp.exe was failing with this error when minutes before it was running fine.
After some investigation we realized that the real problem was in the code of the global.asax: it was throwing an stack overflow exception (pretty ironic for answering here) and that was crashing the w3wp.exe process before VS could attach it to begin debug.
Fixing the buggy code made the VS to run nicely again.
I see the question is from long ago, but I hope it helps somebody.
To solve this issue, let the dialog help you. Agree to launch an elevated debugger and debug your problem. You probably have some sort of configuration problem. Your real problem isn't whether or not the debugger is elevated, it's the fact you need a debugger at all. In other words the first sentence on the dialog is "you have a problem." All the other sentences are "I would like to help you with that problem; is that cool with you?"
I believe an update to the latest version of VS and .NET Core 2.1 is what caused this for me.
Then for the first time, I noticed this setting. Setting it to 'Enabled' fixed it for me.
If you usually attach to process and debug but you can't (because you can't get the app to successfully run), run the app via Visual Studio and it'll break and show you the exception cause in some detail.
Please check for System.Diagnostics.Debugger.Launch(); or Debugger.Launch(); in the cs file. Commenting the code, starting the application worked fine for me.!
I was experiencing this error because of the AppPool that was associated with my site. Originally, I was using DefaultAppPool. The fix was to use a different app pool (custom, from our app) that had NetworkService as the identity.
In my case it was stackoverflow due to circular dependency injection
public class ServiceA : IServiceA
{
public ServiceA(IServiceB serviceB){...}
}
public class ServiceB : IServiceB
{
public ServiceB(IServiceA serviceA){...}
}