I use Delphi 10 Seattle and I want to debug some package. The sctructure is like: host VCL application (for debugging purposes, Windows service otherwise) and several BPLs with application logic (one main BPL and some others with model and some infrastructure). These packages are set to be runtime packages.
Now I want to debug some issues and I want to put sume breakpoints and inspect the code and variables values (not very exotic requirements). And here comes the problem. The host application runs fine, everything appears to be OK - during the loading of the app all packages all breakpoints turn from green to blue (so it's source had been loaded) and the application starts. When any breakpoint is hit, the execution stops at this breakpoint, but the view jumps into (for me useless) CPU view.
I believe (and GIT as well) there were no changes in the source of the host including project files since the last version I was able to debug.
Edit:
Another interesting scenario:
If I create a blank console application, with a single writeln and put a breakpoint on it everything works fine. If I add one of our packages as a runtime package (even without referencing it in uses clause or anything else), the breakpoint in the console app ends in the anoying CPU view...
Well, still use D2007 and deal with equal issue(s) on a runtime package.
While using the EQUAL compiled Source (have them on a non dependent HD) while boot with different OS as Win7 & Win10 1803 & Win 1809 HD's:
Win 7: I get the source shown :D
Win 10: sometimes when I alter on the main project (as adding the package of interest) I will get the real debugging source shown. Or added on the main project on the Interface/Uses an unit of the runtime package.
Now on a different Win 10 OS same workaround did not helped at all.
The problem I see, that the package loading on the Debugger itself is optimized, so that not all units within the package & unit gets initiated.
My current Win 10 solution looks like: within the main module startup, do the package loading & initiating by yourself and without any unit usage or package loading list!
Required is, to provide within the main project & debugger the source path path of this package!
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!
What is the registry subtree HKCR\VBKeySave5 for? Why does it have such a huge effect on VB6 IDE performance?
Background:
One of our development PCs (Windows 10 x64) had a very slowly loading VB6 IDE. The IDE was slow to load initially, and very slow to bring up the project references window. (Tens of seconds, or even ~minutes).
Purusing the registry for one of the libraries used by the project revealed the subtree HKCR\VBKeySave5. Under this subtree were thousands of entries that looked like the usual COM marshland of GUIDs, class IDs, classnames, etc. which you get with VB6 DLLs, etc.
Deleting this key and everything under it made the IDE perform immeasurably faster - basically it would load and then show the references window instantaneously.
Nothing bad seemed to happen as a result of this.
It appears that the VBKeySave5\ subtree is used by the VB6 IDE when running with multiple projects in a group.
When running in the group, VB6 cleverly makes all the COM references that normally be served from a compiled DLL actually redirect to the IDE, so you can debug right into projects in the same group. It seems to use the VBKeySave5\ subtree to implement some of this wizardry.
I made a test project which contained one test DLL. Then made a test group containing both. Using Process Monitor I spied on what the IDE was doing in the registry. This is the basic sequence of events:
Load project group
Run project group - debugging begins
IDE creates the VBKeySave5\ subtree
IDE populates that subtree with a bunch of stuff
Test program executes in the IDE / debugger
Test program terminates
IDE removes all the stuff under VBKeySave5\
IDE returns to edit mode (debugging ends)
In that scenario, nothing extra is left in the registry.
Now - if after step 5 I killed the VB6.exe process, all the registry junk it added never gets removed. And running VB6 again and running the same group doesn't clean it up -- it just creates slightly different stuff under VBKeySave5\ instead.
So over time, especially with larger projects, cases when the IDE terminates abnormally add tons of useless clutter to the registry. And it appears this clutter still has to be read through by the IDE when it loads the project, etc. slowing it way down.
In our case, for whatever reason the IDE crashes a lot. And we use project groups (with 4, 5, 6 projects) regularly. So it appears that these crashes junk up VBKeySave5\ with lots of entries, and that causes the slowdown.
Maybe there are also situations other than crashes where VB6 doesn't clean up after itself.
There are scant Google results for VBKeySave5, but this one has an anecdote about 75,000 entries under that subtree
On my own PC in a recent example, I exported the VBKeySave5 key to a file. The file was 98 MB having 1,013,090 lines.
Additional information related to why VBKeySave5 might not be cleaned up automatically:
The VS Installer for Windows 10 allows you to set the VB6.EXE
compatibility mode to Windows Vista (Service Pack 2).
DO NOT DO THIS.
Do not run the VB6 IDE in compatibility mode of any kind. The
suggested purpose is to fix anomalies in the graphic designer of the
IDE. Believe me, these anomalies are nothing compared to the damage
left in your windows registry when VB6.EXE is run in compatibility
mode.
When VB6.EXE is used to Compile-And-Run your application, it replaces
GUIDs and class and typelib registrations causing them to refer to its
VB6DEBUG.DLL. this allows the IDE to intercept execution of your code
so you can debug. When it does this replacement of your DLL and OCX
registrations, it saves your stuff under HKCR\VBKeySave5.
Unfortunately, when VB6.EXE is set to run in compatibility mode of an
earlier verison of Windows, it fails to restore all of your DLL and
OCX registration information. It leaves VBKeySave5 there, which causes
your IDE to take much longer during subsequent starts of the IDE, and
it trashes your registry, eventually rendering your application
not-runnable on your machine.
I have a mixed managed and unmanaged C++ application that's working quite well. I'm using Visual Studio 2013 to compile it, and all is well. Recently I upgraded my computer to Windows 10, and now it's not working.
If I get the executable compiled on Windows 8, it runs properly on Windows 10. It only fails if I compile it on Windows 10.
The failure is peculiar as well. I run the EXE and nothing happens. When I run it from Visual Studio it doesn't even reach the first line of main. Breakpoints are all marked as 'disabled'. When I break the running process the debugger shows an empty stack trace.
UPDATE: Hunch about DLL loading turned into a fact:
I used Process Explorer and I see the process has two threads. The one starting at !CorExeMain is stuck at !LdrLoadDll, but I can't tell which DLL that is.
OK, found the DLL that causes the problem. I've created a C++/CLI console application, used that DLL and got the same behavior. The DLL is part of the application (and part of the VS solution). It's a native C++ DLL, compiled with the same compiler and settings. This DLL references other DLLs unfortunately.
This is a generic problem called "LoaderLock". The operating system makes very strong guarantees when it calls the DllMain() entrypoint of a DLL. Strictly in loading order, they never run at the same time. There is a lock in the OS loader that ensures these promises are kept.
And a lock always has the potential to cause deadlock. It will happen when the DllMain() entrypoint does something unwise like loading the DLL itself with LoadLibrary(). Or call a function that requires the OS to have a DLL already loaded. Can't work, its DllMain() entrypoint can't be called because the loader lock is held. The program will freeze. C++/CLI apps are prone to this problem, lots of stuff tends to happen in DllMain(). Indirectly, you can't see it in your code.
You can only see it with the debugger. You must change its flavor, Project > Properties > Debugging > Debugger Type, change it from "Auto" to "Mixed". You'll now also see the unmanaged code that is running including the OS loader functions, name starts with "Ldr". Be sure to enable the Microsoft Symbol Server with Tools > Options > Debugging > Symbols. And be sure to use the Debug > Windows > Threads debugging window as well, the truly tricky loader deadlocks that don't repeat well or appear to be affected by the OS version are caused by another thread loading a DLL.
Diagnosing and fixing it can be difficult, be sure to reserve the time you need to dig in. If you can't make heads or tails of the stack traces then post them in your question.
Before taking #Hans Passant advice I carefully combed through the code, dumpbin /dependentsed the executables and DLLs and made sure there were no custom DllMains. There were none. DLLs were indeed loaded with LoadLibrary, but that was happening long after the loading DLLs were loaded.
So I took #Hans Passant advice. Set up the debugger properly and checked the state of the process during the deadlock. One of the threads was stuck in LdrLoadDll.
It took a little tinkering to find the name of the DLL that was passed to LdrLoadDll. It was AVGHOOK.DLL .
I disabled AVG, and lo and behold - everything is back to normal.
This is the second time AVG is messing with me. The previous time I nearly replaced a printer until I figured out all the PCL errors disappeared when I disabled AVG. I think I'm not going to use it any more.
I have put our comment ping pong into a full text:
#1:
As you found out, that your application did not load, you needed to check if applications on your system (W10, VS2013) run at all.
Reply: A test console app is running fine.
#2:
If your application doesn't run, build up a similar application and step-by-step put code of your app into the new app until it fails.
If the failure is causes by a DLL (which cannot be loaded, as it was in your case), remove DLLs from your app until it works. Alternatively build a dummy console app, include DLL #1 and use some functions of that DLL. Compile, run, check. Go on until DLL #n...
Reply: faulty DLL was found.
#3:
Reference only this DLL in the test app to ensure it's this DLL only and not a combination of DLLs.
Is it a managed DLL or a native C++ DLL?
If the faulty DLL is from a foreign source: bad luck. Ask the developer for support.
If it's your own: Did you compile the faulty DLL on W10+VS2013, too, or did you copy it from your previous system? I suggest you compile this DLL again on the new system.
Reply: it's a native C++ DLL, which is part of the solution and is compiled together with the main app.
This DLL references other DLLs unfortunately.
#4:
Create a new console app, that references not your faulty application DLL, but the DLLs which are referenced by YOUR DLL. Omit the intermediate step to detect if the failure comes from the other DLLs.
The general procedure is: Split up faulty code to find out out which part is causing trouble. Romans already knew this 2000 years ago: Divide et impera ;-) Though they did it in a different context...
We had the exact same problem here during several weeks ! And we finally found a solution !
In our case, it was the anti-virus Avast which was corrupting the generated .exe !
The solution was to simply disable all agents while generating the release !
If you use another anti-virus, try to disable it.
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.
I've tried many/varied troubleshooting techniques:
Full uninstall and reinstall of my application
Manually re-registering all dll's and ocx's that I know are used
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.
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.)
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.
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 MousePointer = vbHourGlass... 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.
(Forgot about this one)
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.
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.
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.
Any ideas or thoughts on how I can track down the root cause of the issue would be greatly appreciated.
Update 1 - Response to questions
#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.
#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.
#Bob77 The application is installed into Program Files (x86). While many of the libraries do reside in the same folder, they are all registered.
Peter, often I've noticed that the debugger will indicate a line of code that is actually incorrect, depending on WHERE in the actual assembly language the fault occurs. You should look REAL close around your statement that sets the cursor to vbHourGlass. Your exception is PROBABLY happening BEFORE that line of code, but that line is what the debugger thinks is the actual faulted line of code.
Since you said it happens when a window OPENS, I'd look real close at any ocx's you may have referenced on the form, but perhaps NOT actually being used, or called. You might have one there that you don't intend to be there, that could be causing security issues, or something on Win7? Edit the .frm file by hand if you have to, and look at all the GUIDs the form references.
It is possible that one machine is using PER-USER registration, and the other is using PER-SYSTEM registration?? I don't know...
I would take a much closer look at the form that you are trying to open, and be VERY cautious of everything you are doing in the form load events, and so on. This sounds like it could be something as stupid as Windows Aero being enabled on one system, and not another, or some other sort of "Theme" setting that is throwing the VB Form Rendering routine into a hissyfit... Perhaps even something as stupid as a transparent color index in the icon you selected for that from?
If you are still developing this app, (or at least maintaining it), create an entirely NEW form, and re-create all the controls, etc, on the form (resist the temptation to copy/paste them from the old one...), and then see if THAT does the trick. Then, copy all the event code to the new form one event at a time, with at LEAST enough event code to make the form function, even if it's just a "dead form", that loads no data, or whatever the form is supposed to do. Check and debug after each change, and you WILL find it eventually. Of course, make sure you isolate one of the defunct systems to have a platform that you can duplicate the issue on, or then it's just guessing. I find that using something like Acronis w/ Universal Restore is a great option to then take the image file into a good HV, like VirtualBox, and then restore that image as a VM, so you can debug without interfering with your actual users. This sounds like a lot of work, but then again, so is re-writing an application that already exists, right? :)
Failing THAT... /* and */ are your friends!! (Well, we're dealing with VB, so ' would be your best friend! heh... But I'd start commenting out all the code on the form until that sucker opens. Then once it opens, start putting one line back at a time, and re-running it... That's called "VooDoo Debugging", but sometimes, you gotta do what you gotta do...
THANKS A LOT PETER! :) Now you got ME so involved in this, I feel like I'M the one debugging this sucker! Like if it was MY code I was trying to fix! :)
Let me know if any of this helps... I am actually quite interested in what you discover.
I have a program that I run on multiple network PCs. When I compiled the most recent version, it runs extremely slowly on 2 PCs on the network, but runs fine for everyone else.
This used to happen with my old dev PC when I had an additional 2gb RAM installed. When I would remove the additional 2gb and recompile, it would then work fine for everyone.
Now, I am on a completely new machine and am having the same issue. I've tried to rebuild the project after rebooting, but still have the same issue.
For all other PCs, the program loads in about 3-5 seconds. On these 2 PCs, it takes anywhere from 45 seconds to 1.5 mins to load...
One of the PCs is an older Dell Dimension 8200, but the other is a newer OptiPlex that is identical to several other PCs on the network, so this is what is really making it so confusing.
For now, I've had to revert to the old version so it will run correctly for everyone.
Does anyone have any idea of anything to try?
Thanks in advance!!!
Edit:
Ok, it was an exhausting day yesterday trying various things to solve this issue. Here is what I tried and where the problem begins:
Using the new program
Went back to old versions of all updated components, but still had the same issue
Using the old program
I decided to go back to the drawing board and start from the old version of the application and incrementally add the new features a small piece at a time.
Recompiled the old version using the old components - program works fine
Updated to new DevExpress components - program works fine
Updated to new ESBPCS components - program works fine
Updated to new DeepSoftware components - program works fine
Ok, so now we know there is nothing with the component sets I've updated...
Added 1 image to each of 2 image lists - program works fine
Added new database table - program works fine
Added code to open and close the new table - program works fine
Added new action to action list and added a menu item and toolbar button to new action (action does nothing at this point) - program works fine
Added a new BLANK form to the application and added code to open the new form - BAM!!!
So, adding just one form to the application is what's causing the issue! I removed all the code for the opening of the form, commented out the uses clauses and removed the uses entry from the project source and everything is back to normal!
Anybody have any idea about this?
Thanks!
Edit 2:
For #Warren P - here is my .DPR source:
program Scheduler;
uses
ExceptionLog,
Forms,
SchedulerMainUnit in 'SchedulerMainUnit.pas' {FrmMain},
SchedulerDBInfoUnit in 'SchedulerDBInfoUnit.pas' {FrmDBInfo},
SchedulerHistoryUnit in 'SchedulerHistoryUnit.pas' {FrmHistory},
SchedulerOptionsUnit in 'SchedulerOptionsUnit.pas' {FrmOptions},
SchedulerExtVersionUnit in 'SchedulerExtVersionUnit.pas' {FrmExtVersion},
SchedulerSplashUnit in 'SchedulerSplashUnit.pas' {FrmSplash},
SchedulerInfoUnit in 'SchedulerInfoUnit.pas' {FrmInfo},
SchedulerShippedUnit in 'SchedulerShippedUnit.pas' {FrmShipped}; {<-- This is the new form with the issue}
{$R *.res}
begin
Application.Initialize;
Application.Title := 'SmartWool WIP Scheduling Assistant';
Application.CreateForm(TFrmMain, FrmMain);
Application.CreateForm(TFrmDBInfo, FrmDBInfo);
Application.CreateForm(TFrmHistory, FrmHistory);
Application.CreateForm(TFrmOptions, FrmOptions);
Application.CreateForm(TFrmExtVersion, FrmExtVersion);
Application.Run;
end.
And here is the intialization section of the main form to create the splash:
initialization
FrmSplash:=TFrmSplash.Create(Application);
FrmSplash.Show;
FrmSplash.Refresh;
Edit 3:
Anybody??? Please?
It could be that the program is waiting for timeouts when trying to access resources that are not available on that machine such as network drives or Internet hosts.
Try running Process Monitor when starting up your program and look for file open calls. Filter the output so it only shows your process.
http://technet.microsoft.com/en-us/sysinternals/bb896645
Performance problems initially can seem very daunting at first.
I have been on many teams where people have tried to guess at a reason for performance problems. This sometimes works, but is far less effective than actually measuring the code.
When reproducible on a development machine, I would recommend a profiler.
There was a previous question that asked about
Delphi Profiling tools which has several possible tools you could use.
When you can't reproduce the problem on your development machine, then it becomes a bit more difficult, but not impossible. Typically I have found that problems are related to an application dependency that is different, and not performing well. Understanding the external influences on your application can help pinpoint the problem.
Specifically common external problems in some of my applications.
Network
Database
Application Servers
Installation or Data File Location (i.e. Disk Performance)
Virus and Malware Scanners
Other application interring with yours such as a virus.
To monitor for items related to the network (i.e. Database, web services, etc...)
I typically use Wireshark which allows me to see if resources are responding in expected times. My most common problem is poor performing DNS and can found using Wireshark.
You can use the AutoRuns program to determine everything that starts up when your computer does, it's useful in determine differences between machines.
But most of all I have logging that can be turned on in my applications and this allows me to isolate the problem to a specific area of code. This narrowing down to a specific section of code reduces the guessing, and allows you to focus on a few possible problems.
I created a log function for this that I call at specific places (in your case especially during startup). It adds a timestamp to each log text and stores them in a TMemo that is regularly saved. Not only very helpful when debugging, but may also shed some light on your problem.
Are you using code signing - ie Microsoft Authenticode? If so, then outdated certificate authorities on the computers can cause significant delays to startup.
First, I would try to defragment the hard disk. If still slow, I would check the power supply. Maybe your hard disk are getting insufficient energy.
Check if there is the same antivirus software on those 2 problematic computers. If so, then your Delphi application may match byte pattern used in some virus made in Delphi. Update virus definitions to solve it, or report false alarm to antivirus company, or change antivirus software.
Check if there isn't any printer installed on those 2 problematic computers. If it is so, then add any printer and try again.
Idea 1:
One reason I have seen for very slow application load time, is when printing or reporting system components like Developer Express Express Print, are in your application.
The problem I saw when using Developer Express Printing components, is that I had an offline or non-responsive network printer in my list of printers (check the control panel printer icon) that was not responding. Some of those Developer Express components seem to read some information from each printer you have installed, and the solution was to go to those clients, and delete old printers from their control panel, that were no longer being used. Each not-responding network printer added up to 60 seconds for a TCP Timeout, to the startup time of my application.
Update - Idea 2:
Download MS DebugView and install it on the machine that runs slowly. Now go back to your main development PC, open the IDE, open your main project file (right click on the project, view project source in project viewer), this will show you the contents of your main project source file (.dpr). go to the main begin....end. block. Now set a breakpoint on the main begin statement, and single step INTO (not OVER) and you will see all the module initialization sections. In each one add this: OutputDebugString('ModuleName').
Now when you run this inside the Delphi Ide you will see messages, and see how far apart they come in, and understand what is taking a long time to initialize. Instead of installing the delphi ide onto the machine that runs slowly, Debug View (which is less than 400kb single executable) will be run, and it will show you these debug messages, along with a nice time display (##.# seconds) for each message.
MS Debug view is here.
Are you allowing the forms to be constructed on initialization within the DPR source? If so, you may do well to consider whether or not you want those forms sucking up memory the entire time, more-over if you want those forms to be wasting the application's time on load.
A rule of thumb: If the form is used a LOT during the application's execution, allow it to be constructed when the application loads (this will work out faster over-all than constructing the instance "on-demand").
If the form is not used very often at all (for example, a Dialog or an About Box), delete the "Application.CreateForm" line from the DPR source, and instead construct your instance on request...
var
LForm: TfrmAbout;
begin
Application.CreateForm(LForm, TfrmAbout);
try
LForm.ShowModal;
finally
LForm.Free;
end;
end;
Now that form (which may not even be displayed during the program's execution) is not sucking up system resources, and will not slow down the application's load time.
It may not solve your problem 100%, but it should certainly help!