I have obfuscated a dotnet winform application with Confuser and then packed with RPX Packer, now the resulting assembly is being given false positive by antiviruses like Kaspersky( deleting it), Avast etc.( Windows defender is OK with it). I am unable to figure out why?
How do i fix the issue
The problem is the RPX Packer which causes some Anti Virus scanners to identify the file as infected. I have had the same problem with a RPX packed executeable today. Think about dropping RPX.
Related
I upgraded from 10.3 (Rio) to 10.4 (Sydney) (with side-by-side installs), now having IDE docking exception, e.g.
Loading the desktop from "C:\Users\gary.walker\AppData\Roaming\Embarcadero\BDS\21.0\Default Layout.dst" for doc host windows "DockSite3" failed with message:
"EAccessViolation: Access violation at address 50165CBF in module 'rtl270.bpl'. Read of address 33DEEBFF"
Deleting all .dst files has resolved the issue in at least one case (a coworker).
Also, when attempting to debug a program, I was having a hard failure during debug startup that prevented debugger use, before application began execution. I resolved this problem by copying my Default desktop to my debug desktop.
Another friend had pretty much the same issue and was able to fix it, unfortunately he does not know how he fixed it.
Question is does anyone know how to fix this?
I am still waiting for an answer from Embarcadero and this is causing us real problems at the moment.
I received an answer from Embarcadero support.
It fixed the problem for me until I adjusted my desktops to the way I wanted them and them - still better than nothing. I suspect there is no solid work-around at this point in time. But, this may work well as long as you are not frequently changing your desktop layouts.
There were display layout changes introduced in 10.4.1 that cause the errors that you are seeing.
Shut the IDE down
In Windows Explorer navigate to: %AppData%\Embarcadero\BDS\21.0
Delete the *.dst files at that location (you can back them up first if desired)
In Windows Explorer navigate to the product's \bin directory. The default location is: 4. C:\Program Files (x86)\Embarcadero\Studio\21.0\bin
Copy the three default *.dst files from this location to the location in step 2
Start the IDE as normal
This question already has answers here:
How can I stop my installer from triggering Windows 10's "This app has been blocked for your protection" error?
(2 answers)
Closed 3 years ago.
I am new to windows development. I packed my project into a msi setup to install on other systems but when I open the msi in any system it shows a warning as attached . How can I remove this warning?
Note: Be sure to check if your organization already has an EV-level certificate? Just a few emails or phone calls might be wise before trying to research the purchase process?
Trust & Reputation: What you really need is an EV code-signing certificate. Microsoft's SmartScreen feature
in Windows (which is what you see with that blue prompt) is a
reputation-based system where unknown binaries are flagged as unsafe until they are validated safe by users in actual use.
Virustotal.com: An EV code-signing certificate "buys trust outright" - interesting concept - and should allow your users to not see such a prompt even for brand new binaries. Make sure to check all your binaries using virustotal.com though, as many malware-scanner detections can trigger a resurged smartscreen warning for any binary - which is what it is for (signed malware is still malware).
False Positives: False positives for malware is a huge problem since you have to deal with it and solve it, and you can't just tell your users to rebuild their PC and try again.
Moral: The moral of the story is to use Virustotal.com to test for both malware and false positives in your binaries and files for distribution, and to use an EV-level certificate for serious software distribution to get trust for your binaries outright (without delay). An EV-level certificate is not a silver bullet. Problems can still be seen. Trust can be lost too, not just gained (trust... hard to earn, easy to lose).
Tip: A properly signed MSI will also show up with the correct name in the UAC prompt: Installshield Custom Dialogue Installer (see screen shot and then the answer a bit down the page).
The Far Side Perspective: "Be sure that your setup is malware free or an applied digital certificate is proof positive that you delivered the malware" (until that is hackable too) :-)
We do our best.
Link:
How to protect MSI against modification (on malware and false positives - recommended)
How to add publisher in Installshield 2018
How to pass the Windows Defender SmartScreen Protection?
Using Visual Studio 2003 Professional under Windows 7 SP1 (64 bit), compiling from the command line, I get a fatal error C1074: IDB is illegal extension for PDB file. The documentation on this error is sparse to put it lightly. The incredibly odd thing about this is that, utilizing the same build script on the same computer but under a different account does not generate this error.
My first guess was that something in the environment variables is causing this conflict, but doing a diff between them for the two accounts, and modifying PATH and INCLUDE to be the same does not fix the error.
Does anyone have a fix for this error, or any idea what actually triggers it? None of the files are being compiled with a /Z switch of any kind, so as far as I can tell, no PDB files should ever actually be generated (and on a successful build, no IDB OR PDB files are generated that I can see).
I was experiencing the same problem with solutions on Windows 7 x64 and Visual Studio 2005 Pro (SP1).
Symptoms
I am using Visual Assist X (currently build 2007). So in my case all I needed to do was to disable IntelliSense by renaming feacp.dl inside C:\Program Files (x86)\Microsoft Visual Studio 8\VC\vcpackages to something else. That fixed the crash at startup (probably unrelated to the issue the OP encountered).
After that the Debug configuration gave me loads of
fatal error C1033: cannot open program database ''
errors, one per file compiled by cl.exe.
With the Release configuration I got
fatal error C1074: 'IDB' is illegal extension for PDB file: <filename>
i.e. the one about which the OP was asking.
Solution
I found the solution more or less by accident elsewhere, reported for VS 2003. In a sense it's the opposite of Luke's answer.
Fatal Error C1074
This error has been reported to occur if the Windows 7 machines have
Windows XP compatibility mode turned on. To resolve the error, turn
off the Windows XP compatibility mode and recompile the solution.
Should you have other issues check the MSDN forums for more help. Its
not the source it sounds more like your settings with VS. I've never
run across this problem before so I'm little help.
That prompted me to check out the settings for devenv.exe (in my case under C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\IDE). It looks like this:
In my case it was set to be compatible with Windows 2003 Server as depicted in the above screenshot. However, the compatibility must be turned off! (checkbox unchecked)
Also make sure to check out and correct the settings for all users by clicking the second highlighted button (UAC prompt will show up if you aren't already running privileged).
This solved the problem for me and I can avoid running VS 2005 Pro elevated all the time.
From information I've gathered on MSDN about issues similar, but not exactly the same:
Since it compiles with no other change than the user account, I believe there's a chance that it could have something to do with the user accounts permissions. Check and see the differences between the users permissions in VS's settings, and in Windows User Settings. The first thing I would try though is to close VS, reopen with Run As Administrator using the account that WON'T compile and see what happens.
In the attempt of sharing the solutions of some of my troubles, and in the hope of sparing them to others, I had the same issue trying to compile a legacy solution in VS2005/SP1 inside a Win8-x64 machine.
No matter what I tried to do, it always stopped there complaining about the illegal IDB extension...
On the other side, the very same solution compiled flawlessly in my previous Win7-x64 box, when run "elevated".
After much struggling I found that I had to use Win8 "Program Compatibility Assistant" (or whatever is named in the english version - my OS is using a different language) and tell it to run VS2005 in a Win7 elevated environment. After that, the obscure "IDB is illegal" error disappeared at once!
Hope this will help someone =)
I am just learning Blend/Silverlight/VS2010/.net/etc. I have a simple project that resides on a network drive. When I tell VS2010 to rebuild the project, I get the following error message:
------ Rebuild All started: Project: MySilverlightApplication, Configuration: Debug Any CPU ------
MySilverlightApplication -> H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\Bin\Debug\MySilverlightApplication.dll
C:\Program Files\MSBuild\Microsoft\Silverlight\v4.0\Microsoft.Silverlight.Common.targets(214,9):
error : Could not load the assembly
file:///H:\PRJ\VisualStudio\ExpressionBlend\Unleashed\MySilverLightApplication\MySilverlightApplication\obj\Debug\MySilverlightApplication.dll.
This assembly may have been downloaded from the Web. If an assembly has been downloaded from the Web,
it is flagged by Windows as being a Web file, even if it resides on the local computer.
This may prevent it from being used in your project. You can change this designation by changing the file properties.
Only unblock assemblies that you trust. See http://go.microsoft.com/fwlink/?LinkId=179545 for more information.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
The project was not downloaded from the Web (I created it using Blend.) After doing some searching, I guessed the problem may be due to .net security settings. I issued the following command:
C:\Program Files\Microsoft Visual Studio 10.0\VC>caspol -m -ag 1.3 -url "file://\\p4dc\h$\*" FullTrust
in the hope that would solve the problem. p4dc is the name of the server machine, h$ is the administrative share for the h: drive on the server which in turn is mapped to the drive letter "H" on the local machine (\\p4dc\h$ is mapped to H in the local machine).
That did not solve the problem. I don't know if my caspol command is correct (I wasn't planning on learning caspol on the fly), it just seemed like a reasonable thing to try. The problem goes away when I make a copy of the entire project on the local C drive but, that "solution" is rather undesirable.
At this point, I don't really know what else to try to solve the problem without moving the project to a local drive.
Any help leading to a solution is much appreciated.
John.
The error message displayed by VS2010 would lead anyone to believe the issue is with trust and security and it is BUT, no amount of allowing full trust on the network drive will solve the problem.
What lead to the solution was first to port the project to VS2008 to find out if it would encounter the same problem. VS2008 was perfectly happy to run the project without complaint.
Then I converted the VS2008 project (which was working) to VS2010. VS2010 refused to build the project but this time the error message was different, referring to "remote assemblies" and to a link on MSDN, which led to the solution.
The real problem is that VS2010 considers an assembly on a network drive a "remote assembly" (the same as if the assembly were being loaded from a web site.) Caspol was not able to solve that problem (it seems it should have but, it may be my fault, I am not well versed in using Caspol).
To end this long story, the link provided in the error message is:
http://msdn.microsoft.com/en-us/library/dd409252(VS.100).aspx
after following the instructions in that link to edit "machine.config", I changed <runtime/> to:
<runtime>
<loadFromRemoteSources enabled="true"/>
</runtime>
the project built successfully and ran without a hitch.
Thank you to Alison and CodeNaked for their efforts to help,
John.
PS: it would have been rather nice if VS2010 had displayed the "better" error message initially. Instead, I had to port the VS2010 non working project to VS2008 where it worked and that one to VS2010 where I got the better error message that led to the solution.
Not sure if this will help but it's worth a shot: How Do I Allow my Visual Studio .NET Projects to Run from a Network Location?
I'm having an issue with VS 2010. It's running very slow and also crashes occasionally when compiling and packaging a xap file with the following error:
Xap packaging failed. Exception of type 'System.OutOfMemoryException' was thrown.
In the local Windows 7 temp directory \Users\usernamexxxx\AppData\Local\Temp
there are thousands of files, so I removed them and now VS is much faster.
Is anyone else having similar issues?
Yes, I have simmilar issue. when I clear My Temp Memory It works fine but after some time Temp directory is also showing some file.
and again the message comes "Out of Memory Exception".
It is an issue in Code. Your code is leaking memory. your code is not disposing object properly.
I haven't had that type of error message, but the thing that always seems to slow down VS 2010 for me is the .suo (Solution User Options) file. It basically keeps track of what files you have open, and your break points, but it is an always growing file. When it get's up to 5mb, it can take 20-30 seconds for VS to respond at times when adding a file, or deleting one from the solution.
I got tired very quickly of visual studio's slowness. My solution was to build everything on the command line using msbuild. I created a batch file which calls msbuild with my preferred options.
This option is actually really nice, because if you have a multi-core machine, you can pass the /m flag to msbuild, which will allow the build projects in parallel when possible (Visual Studio currently doesn't offer this functionality, but will in VS2012)
Calling msbuild is easy. For example:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\msbuild.exe MyApplication.sln /m
Then, if I want to debug, I just build first (on the command line), run the app, and attach the visual studio debugger manually.
I'm not familiar with this error in particular, but had an nasty issue back then with OutOfMemoryException during compile time for a big solution (more than 50 projects)
We used to circumvent it by using msbuild directly but debugging was a bit cumbersome
I checked on internet then and tried to extend the virtual memory that devenv.exe was using (by default it's 2GB).
Being on a 64bit Windows 7, the OS was already complying with the fact that an application could use more than 2GB.
Just had to fire up a command prompt and type :
cd\
cd "C:\Program Files (x86)\Microsoft Visual Studio 10.0"
copy Common7\IDE\devenv.exe Common7\IDE\_devenv.exe
VC\bin\editbin.exe /LARGEADDRESSAW Common7\IDE\devenv.exe
After a reboot, the compilation Exception was just a mere dream.
Note : I read afterward that Visual Studio 2010 was supposed to be Large Address Aware out of the box, so it shouldn't have "solved" my issue, but it did for me.