I wanted to try out the TCC and got the Win32 Binary zip file from the website.
upon decompressing it I tried to compile the "hello_win.c" source from the example directory. As soon as the compiler tried to write to the disk McAfee Popped up a dialog box and identified a Trojan named "Generic.dx." Has anyone else experience this? Dropping a virus into a compiler would be a sneaky, but brilliant, delivery mechanizism. I just want to know if this is a legit threat.
Have you tried any other virus scanners? McAfee is notorious for false positives. What does the TCC website say about it? Have you googled it? I'd rather doubt it is actually a virus.
Upload your *.exe file to http://www.virustotal.com/ to see which Anti-Virus scanners react to the file. I have had similar issues with Delphi. (See discussion at Wikipedia.)
By definition, compilers modify executable files. It is quite possible that your antivirus is flagging this behaviour as a "generic" virus. If you download your executables from a reputable source, and if they pass virus detections inside tcc.exe itself, most likely this is a false warning.
Related
This is the error messsage I get.
I know it's kind of an eye roller, that it's difficult nigh impossible to tell what I may need without the source, but it seems like a deployment problem as people that installed the Qt SDK can run it. Plus, I figured I'd have better luck asking here than with a chinese developer that speaks google-english.
So here's what I've done:
I installed the MSVC2012.
I used a program called cffexplorer to see what the exe was looking for. I have the 7 or so .dlls that are at the top of the tree.
I found a recent (jun 2013) qwindows.dll from elsewhere on my system and put it in ./plugins (I've tried this file in ./, ./plugins, and ./plugins/platforms
I created a qt.conf with the following data (I determined the format from an existing Qt based app that works)
[Paths]
Plugins = plugins
Yet, I continue to get this message. Any suggestions on what I might look for to clear this up?
Ask the developer what compiler was used to build the application. Then you will need the right dll (that was built with the same compiler as the application). Also notice that (by default) the documentation says that qwindows.dll should be in the platforms folder in the same path as your executable, read more here. Depending on whether the developer used a Qt built with angle, you may also need: libEGL.dll and libGLESv2.dll. Dependency walker might help you find dependencies that are not there.
I'm writing a program that download a file(dll) from my server and use this file.
But, when the download is complete, my antivirus (Kaspersky) detect my file with Constructor.Win32.Downldr.xr. How can I solve this?
However, I put my 2 files in www.virustotal.com and both have no virus.
Note: The two files (the program that makes the download and the file, that is a dll) are made in Delphi 7.
You can't expect to bypass the anti-virus software so that leaves two options:
Persuade the AV vendors that your DLL is clean and get them to update their signatures.
Change your DLL sufficiently so that it does not fall foul of the scanners. That's going to require trial and error I guess.
In a previous question you asked how to download a DLL file to memory and then load it from memory rather than a file. I expect most good anti-virus software would regard any software that does that as being malware.
If I were you I would download to a temporary file and use the officially supported LoadLibrary to load the code. The AV software may be more lenient to that. If you are not prepared to do that then your software probably is malware in my eyes, even if you don't mean harm. Even if you do that, downloading and executing DLLs from the internet without the user's explicit consent is verging on malware in anyone's eyes.
Let's put it another way. I would never let this program of yours run on my machine and I would be pleased when my AV software flagged it.
You may also try to use HTTPS or any secure connection when downloading the file. Some antiviruses can't look to cryptographed connections.
Users have been reporting problems/crashes/bugs that I can't reproduce on my machine. I'm finding these problems difficult to fix.
I've started using EurekaLog (fantastic!) and SmartInspect. Both these tools have helped greatly but I'm still finding it difficult to catch some problems.
I've just purchased Debugging by David Agans (and waiting for it to arrive).
Are there any other tools or techniques specific to Delphi that will help with catching these hard to find remote problems? The kinds of problems I'm finding difficult to track down are those that don't raise exceptions or have a clear cause. EurekaLog catches exceptions and SmartInspect is pretty good once I have a theory to check. But in some cases it is a seemingly random crash and there are several thousand lines of code that may may be at fault. How to narrow down to the root cause?
MadExcept is what I use, and it is fabulous. I have also used EurekaLog and find the functionality almost exactly identical, except that I have more experience and time using MadExcept. it's free for non-commercial use, and reasonably priced for commercial use.
Update: MadExcept 4 is now out and even supports 64 bit Delphi XE2 apps, and has memory-leak checking too.
When nothing blows up, I rely on heavy use of trace logging. I have a TraceMessage(integer,string) function which I call throughout all my apps, and when someone has problems I get them to click a menu item that turns up the debug trace level to the most verbose level; it gives me a complete history of everything my application did, and this has helped me even more than madExcept, to solve problems at customer sites. Customers get a crash, and that crash report sent by madexcept contains a log file (created by my app) that is attached automatically. I believe you can do this equally well with madExcept and EurekaLog. If you need a logging system you could download Log4D, or you could write your own, it's pretty simple.
For always-free, try JclDebug, which requires more work to set up, but which has worked fabulously for me, also.
For help with heap problems, learn more about fastMM (full version) debug options.
And you shouldn't forget that Delphi itself supports Remote debugging, if you can reproduce a crash on machines in your office that don't have delphi installed, use remote debug across the office network instead of installing a complete RAD Studio installation on that other machine at your work. You could also use remote debug to connect to a client PC computer across the internet, but I have not tried remote debug across the internet yet, so I can't say whether it works great over the internet or not. I do know that since remote debug doesn't support automatic deploy of the EXE file you built (you have to do that part yourself), remote debug over internet, to a client PC is more work.
You might also find lots of your problems by fixing all your hints and warnings, and then going through with CodeHealer or Pascal Analyzer (PAL) from Peganza. These static analysis tools can help you find real code problems.
If performance and memory usage are your problems, get the full version of AQTime, and use it to profile and watch your system operate. It will help you fix your memory leaks, and understand your app's runtime behaviour and memory usage, not just leaks but bottlenecks for memory and CPU usage. Some of those bottlenecks can also be the source of some odd problems. I have even used AQTime to help me find deadlocks, since it can generate traces of execution, that can help me figure out what code is running, and locate deadlocks. Update: AQTime is not installable on machines other than your main dev machine, without violating the newly modified license terms for AQTime. These terms were never this restrictive in the good old days.
If you gave more exact idea of what your problems are, I'm sure other people could give you some more ideas that are specific, but all of the above are general techniques that have served me well.
One of the best way is to use the Remote Debugger that comes with Delphi, so you can debug directly the application running on the remote machine. THe remote debugger is somewhat buggy in some Delphi releases, and requires to follow the instructions carefully to make it working, but when needed it's a tool to consider. Also check if there are updates available for your version, they could come in a separate installer for deployment on "remote" systems. Otherwise first install the remote debugger, than check if the files installed has newer versions in your local installation, and the copy tehm on the remote machine.
CodeSite has helped me a lot in these situations. Since XE it is bundled with Delphi.
Logging is the key, in this matter.
Take a look at our TSynLog class available in our Open Source SynCommons library.
It does have the JCL Debug / MadExcept features, with some additional (like customer-side profiling, and logging):
logging with a set of levels;
fast, low execution overhead;
can load .map file symbols to be used in logging;
compression of .map into binary .mab (900 KB -> 70 KB);
inclusion of the .map/.mab into the .exe;
reading of an external .map to add unit names and line numbers to a log file without .map available information at execution;
exception logging (Delphi or low-level exceptions) with unit names and line numbers;
optional stack trace with units and line numbers;
methods or procedure recursive tracing, with Enter and auto-Leave using interfaces;
high resolution time stamps, for customer-side profiling of the application execution;
set / enumerates / TList / TPersistent / TObjectList / TContainer / dynamic array JSON serialization;
per-thread or global logging;
multiple log files on the same process;
integrated log archival (in zip or any other format);
Open Source, works from Delphi 5 up to XE.
I wish to debug executables for which I have no code, using the Delphi Debugger.
WinDBG and other debuggers are no option in this case, as the given executables all call into my DLL, for which I do have code, obviously. My ultimate goal is, to see a stack-trace right down into the functions of the running executable.
I do have symbol-information for these executables, so I was hoping I could write my own .RSM files for this purpose. Will this work? Will the Delphi debugger pick up any .RSM file that it can find? And would that mean that other debug-information should be left out?
Do note that there are lots of executables that I need to debug, and for all of them I detect the symbols inside them myself, using a moderately advanced function-detection algorithm. So my main problem mainly is how to write .RSM files. For this I have to know the structure of the .RSM file-format. Is there documentation or example code available somewhere that shows me how to create such a file?
Any help is appreciated!
PS: Might you be wondering why I'm doing all this : It's all related to Dxbx - an open-source Xbox1 emulator. See sourceforce for details. New members are welcome!
I found a page that says the format is similar to CodeView (www.openwatcom.org/index.php/Debugging_Format_Interoperability)
There is a link to this reference at Microsoft's CodeView format specs
I doubt this fully answers your question, but maybe it will get you a little further?
I am attempting to use WinDBG or another debugger to debug a CodeGear Delphi 2007 Windows application on a remote machine. I have been unable to produce symbol files for WinDBG.
Is there a way to use WinDBG or another debugger to debug Delphi applications on a system that doesn't include the IDE?
Edit1
The remote debugger is not an option here. I am able to remote in to the end user PC, but I am unable to use the remote debugger due to firewall restrictions.
Edit2
I am able to remote in to the machine, but can not connect the CodeGear remote debugger due to firewall restrictions.
How about the remote debugger? Build your app with remote debug symbols and debug from your development machine across the network.
instead, i rely on MadExcept stack tracing and some logging features. my application is distributed worldwide & this has been sufficient.
You can try generating a map file and then convert it to a dbg file using map2dbg from
http://code.google.com/p/map2dbg/
Then you can load the dbg file in WinDbg.
Disclaimer: I had faced a similar issue but I managed to do remote debugging and didn't have to do all this. So I am not sure this will work. But if you try it then do let us know if it works.
I'm afraid this is one more of those "I don't have an actual answer" answers, but it might just help...
Have you considered adding logging to your application? I've heard great things about SmartInspect. With it, you can log all sorts of information, including stack traces and "watches" (variables).
Another logging product for Delphi is EurekaLog.
In Delphi you could use Run -> Attach to Process, select the remote machine and select the process you'd like to debug.
http://sourceforge.net/projects/tds2dbg/ can be used to convert Delphi's TDS debug files to DBG files. This gives basic symbol information -- functions, classes, units, but not variables. Enough for a reasonable call stack, and with a bit of knowledge, enough to debug Delphi apps live and with dumps.
I've written about some of Delphi+WinDBG experiences on my blog: https://marc.durdin.net/2015/11/windbg-and-delphi-a-collection-of-posts/
Thank you all for the great suggestions and interesting products.
To solve this specific issue, the "best" way I found uses the OutputDebugString located in the Windows namespace. This, along with Debug View from Sysinternals, will allow me to gather debug information and sort through it pretty quickly.
If you decide to use this method, make sure everything is wrapped in ANSI formatting. IE:
OutputDebugString(PAnsiChar(string1 + string2));
This makes sure that string1 and string2 are combined and then converted in to ANSI Characters.
I probably should have just started dumping text to a file for something quick and dirty, but this will allow a non-debugging version to emit debugging messages.