It was fine few months ago. but then suddenly "windows defender" and "windows security essential" are starting to delete my exe and say it is a Trojan:win32/...
But all other antivirus programs say my exe is fine, no virus detected.
What's wrong on earth?
My exe locates in a same folder with other exe files, all exes are written by me in c#, and copies some file and acts like an updater.
My other exes are fine with windows defender and security essential. But only that one exe, acts like updater, is look like malware by them?
What should I do?
Antivirus programs use algorithms that attempt to predict whether an unseen program contains a virus. They do a great job overall but sometimes get it wrong.
Each major antivirus maker has a means to submit a false positive (your exe in this case). For Windows Defender:
https://www.microsoft.com/en-us/wdsi/filesubmission
In my experience, false positives are often corrected within a few days.
Related
I have an ancient program that I use for reading and writing data from AutoCAD. This program is written in Delphi 5. I have tried to update it to a newer release but several of the libraries I use no longer exist and it is a huge program with lots of libraries used.
The program uses the ACAX##ENU.TLB type library that is provided with AutoCAD. Where ## changes for each AutoCAD release. Every time Autodesk sends out a new AutoCAD version I import the new type library and life goes on.
Now I am faced with Windows 10. For some reason the automation links between my program and AutoCAD are not working in Windows 10. Did something change about the way the type libraries work between Windows 7 and Windows 10? Something that Delphi 5 is no longer compatible with? Maybe it's a 16bit vs 32bit vs 64bit issue. That is all over my head but I understand that Windows 10 dropped support for some 16bit operations. But my program itself runs perfectly. Even the BDE can be made to work which is amazing to me.
Is there anything I can do for an experiment? I am really lost about what to even experiment on.
Thanks.
Well, it's been a long time since I asked this question but here is an answer:
I was able to get my Delphi 5 compiled program working with AutoCAD 2017 in a Windows 10 environment. I am pretty sure that the solution was to run the program WITHOUT administrative permissions and WITHOUT any compatibility modes switched on. Apparently Windows places restrictions on COM communications as soon as you turn on either of those features. There may have also been issues with Windows 10 still having UAC active even when you set UAC all the way off. There is a registry setting to actually set UAC to off but my corporate IT prevents turning that off even with admin rights.
So in the end it was not a problem with Delphi, my program or with AutoCAD. It was a Windows 10 problem.
There was a bit of a clue that might be helpful to others: with the admin permission and/or windows XP compatibility turned on the program took several extra seconds to boot. With the settings turned off it booted quickly.
Or maybe its something entirely different from any of this. But the program is working now.
Thanks.
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
I've been banging my head against this for the past two days and can't seem to make any progress...
Pretty much from one moment to the next, Delphi XE2 won't properly compile one of my projects any more. That is, it actually compiles without errors but at runtime I get resource not found errors for what is essentially the main "form" (it's actually a data module in this case). I have already reverted to older versions of the project from source control that I know were definitely working alright but to no avail. Judging by that it seems it must be something inside Delphi/the IDE itself rather than in the project source. However, I have also not been able to reproduce the issue with a simple test project nor with any other real-life projects... It only happens with this one.
Another strange thing is that when I look at the produced binary with XN Resource Explorer everything looks as it should: The form resource mentioned in the error message is actually there and intact...
At some point I was suspecting this might be caused by a bug in one of the experts I have installed in my IDE (e.g. Uwe's platform and OI experts and VersionInsightPlus, Andreas' IDEFixPack and DDevExtensions, GExperts) but even after disabling all these the problem persisted.
Unfortunately, I am unable to track down exactly when this started to happen as I had been working for some time without actually running the binary, fixing compiler warnings and errors for the x64-target, adjusting build events for updated third-party tools (localization and license protection) and such things...
Has anyone else ever seen anything like this happen? Any more ideas on how to pin this down?
Some more details about the project:
It is an addin for Outlook built using the Add-In-Express framework (i.e. a COM-DLL).
The "main form" is a TDataModule-descendant - we also inserted our own ancestor-class into the hierarchy, i.e. the "addin module" is not directly inheriting from TadxCOMAddInModule - the resources of the custom ancestor forms also appear to be present and intact in the output binary when checking with a resource viewer.
Built without runtime packages for the Win32 and Win64 platforms.
Let me know if you think I missed to mention any other potentially relevant details.
Update:
I have now transferred the sources in question onto a different machine. Interestingly, the DLL I compiled there did not exhibit the problem - on that machine that is... when I transfered it back to the original machine and I tried to call it, the error was back (to stress this: this was the exact same DLL producing a EResNotFound on one machine but not on the other. Of course, once I had discovered this, I also performed the reverse test and lo and behold, the DLL compiled on the original machine works without errors on the other machine...
Seems this might not be a Delphi problem after all... but what is it then?
Differences between the two machines:
Machine 1 (the one were the problem occurs): Windows 7 Ultimate English 64bit with Delphi XE2 Update 4
Machine 2: Windows 7 Professional German 32bit with Delphi XE2 Update 3
On a third machine that is almost identical to the first except that it doesn't have Delphi on it, DLLs produced by both machines work flawlessly.
I am a bit surprised to see your question here. :)
We faced a number of serious issues with recent Update 4 for Delphi XE2. Though we have never run into or been reported of the "resource not found" error, I think this update might be one of the causes. Have you installed it?
One more thing that comes to my mind is images that you use for your Office controls (command bar and ribbon). Probably they got broken somehow, the run-time code cannot load them and reports this error.
Anyway, as you understand, these are just my guesses, if you need our assistance with your office add-in please contact Add-in Express support service, we will try to help.
Update: Seems I was a bit too quick, drawing conclusions. Apparently the Sisulizer solution is also supposed to perform a fallback to the main resource block. I have now taken this issue to the product forum and will report back here, once this is resolved.
Alright, mystery solved at last:
I had turned off the option to "Copy all resources" in Sisulizer in an attempt to reduce the size of the produced resource DLLs and then had forgotten about it...
I hadn't fully realized the implications of the standard Delphi resource DLL approach to localization on which Sisulizer "piggybacks" - especially that it was an all-or-nothing deal: Our previous translation solution implemented a fallback-mechanism that would read any resources not found in the external resource DLL from the host binary instead. This does not appear to be the case with Sisulizer - at least not out of the box... thus, any resource that's not contained in the localized resource DLL does not exist as far as the application is concerned.
I also didn't realize that the mere existence of a file with the same base name as the main binary and an extension matching the current system's default locale (such as .EN or .DE) would automatically cause the VCL to load it...
The machines that did not exhibit the error either still had the older, larger (=complete) resource DLLs on them, or no resource DLLs at all.
HI:
I've a Delphi 7 program that I wrote many years ago, but I've lost the source code. It's a small program but very useful for me.
I've tried to 'install' it again in a new Windows XP computer, just copying the folder with de data (.db paradox files), and configured the BDE connection.
When the programm starts I receive an "Unknown exception" and halts. I've no idea why this happens, and can't debug cause the lost source code. I've tried in another computer with the same results.
Any suggestions or ideas? What do you do in a situation like this?
Thanks in advance.
EDIT:
When I installed Delphi 7 in the new XP computer, the exception came from unknown to known. It was something related to the folder for the Paradox.net file. Thnk you all.
Delphi IDE can attach to a running process and debug it (Run -> Attach to process), although without debug symbols you will end up debugging plain assembler code, which requires some knowledge of assembler and how a Windows application works. And debugging startup exceptions could be pretty difficult if the debugger can't start the program. You can also use the WinDbg debugger from Microsoft.
There are disassemblers (I used the very powerful IDA Pro) that are able to recognize standard library calls helping analysys a lot. You may also find decompilers, although decompiling native applications is a bit more difficult than with those using a p-code or the like.
If the error is not due to a misconfiguration, patching a binary file is not easy.
You can use any debugger, either Visual Studio one, or a free OllyDbg, don't know if Delphi IDE have a simple external-exe-debugger.
But debugging will be very hard w/o source codes, and you must have at least basic knowledge of Assembler Language and win32api.
Alternatively you can use tools like FileMon & RegMon to examine your app activity and find potential problems.
You can try "Run|Connect to process..." in the Delphi IDE. But what zed_0xff said regarding debbugging without sources still applies.
I would go for the disassemble approach like ldsandon suggest, especially since you have (some) knowledge about what your exe is doing.
Besides IDA Pro also take a look at tools aimed specifically at Delphi such as IDR (Interactive Delphi Reconstructor), DeDe and PE Explorer.
To make sure it is not BDE related, I would build another rudimentary application trying to access the same data on this machine.
Once this application works, you can move on to test on the Pascal code side of things.
I have had my share of BDE oddities so I'd prefer to rule this out.
I've created an auto-updating application which is distributed to 100s of users.
The auto-update utility is being flagged by 55% of antiviruses on virustotal ( link ).
My application was created in Delphi 7. Most of the flags are saying that this is Generic trojan/malware, obviously the software isn't actually malware (I'm the only one with source code access and access to the server which hosts it) but it's causing a lot of users to be
Does anyone have any idea how I can stop this being wrongly flagged?
If, as you stated, empty form applications get rated as virus, you might very well be infected by the Delphi virus. More info about this... thing:
http://www.delphipraxis.net/topic163041_virus+infects+delphi.html
http://www.viruslist.com/en/weblog?weblogid=208187826
Virus in Delphi 7
http://www.itwriting.com/blog/1717-delphi-developer-virus-exposes-weakness-in-anti-virus-defences.html
In addition, you use Delphi 7, which is a target for this virus (as far as I know not all Delphi versions are).
Delphi 2007: New VCL Application
Compile without changing anything and some antivirus packages will report the resulting EXE as a potential virus/trojan. Change the name of the main form or add a second form to the project etc and antivirus warnings disappear. Undo the changes and they come back (so it's not a D2007 port of the "Delphi Upgrade Incentive Virus").
My guess is that someone, somewhere once upon a time wrote a virus/trojan/malware with Delphi and the signature/heuristics associated with that now sometimes unfortunately collides with other Delphi apps.
I think you have two choices:
a) Submit your auto-update program as a false positive to all those companies, (and do so for any new versions that are detected). Make it easier for them by ensuring your meta-data is correct and signing perhaps.
b) Split up the functionality so you don't have a single Delphi program that downloads files from the internet, overwrites files and patches files.
It depends - if the 100s of users are on a corporate network, using the same enterprise antivirus software administered by group policy, one solution could be to specify your software as an exception in your antivirus package.
I would try to refactor the program, changing names, changing the order of the procedures and methods, some program structures, removing, replacing, and adding code.
Submit each change to VirusTotal.
You might eventually detect what is causing the problem.
If your program "modifies" an executable, it will be picked up by a lot of AV programs.
I've even seen Borland's patch program that was distributed with Delphi 7 flagged as a generic virus when installed fresh off the CD.
I'm not sure there is much you can do about it, unless you can turn that "feature" off in the AV program or have the rights to add an exception for it. Personally, I think it's just a lazy "catch-all" created by the AV software writers.
AV software also check the Import Table for common API used in viruses, though I don't see any API that will trigger the AV software in the scan report.
See my post at anyone having problems with delphi 2010 and norton internet security. Lately I have been getting SONAR errors too with Delphi 7 compiled programs (and by programs compiled with other compilers).
I reported this to Norton, look also at hot issues at Norton board.
Of course this is only Norton, you don't specify which virus checkers you encountered.
We got the same problem here...
Ant-virus detect some behaviors of our software too.
The ant-virus company doesn't say exactly what they watch (sure, security issue).
Here for example I got this problem when I started using pipelines.
What we did ? We call the security companies, they analysed our .exe, and now we have "white flag" on them.
...No, it isn't so fast process.