is it possible to run CBMC as stand alone witout Visual Express ? Do I need to recompile it or is
there another trick maybe ?
I only need to use CBMC to translate a function to CNF regularly, so I want to call it with
the function name, write the cnf file to disk and start again. I do not want to use Visual Studio.
It is entirely possible to run The CBMC model checker as a standalone program.
I do it weekly on both Linux and Windows 7 :)
I'm assuming you're on Windows because of Visual Studio.
Open a command prompt and navigate to the folder where cbmc.exe is, and call it like so: cbmc --help ...to see the options you have.
The user manual has a section on how to do it, in 3.2 Command line interface.
You may have to call the batch-script that sets up Visual Studio's environment for the CLI (VSVARS32.bat / vsvarsall.bat etc).
On some Windows machines, that script is placed in c:\program files\microsoft visual studio\[version]\vc\bin\ if I recall correctly.
See this MSDN page for more info on that: https://msdn.microsoft.com/en-us/library/f2ccy3wt.aspx
Related
I have a Visual Studio solution which I'm trying to build using the Incredibuild tool. Two of the projects in the solution work in tandem - the first project (we'll call it "Project A") builds an executable (foo.exe) which can parse a data file in the second ("Project B") to generate some header files.
Obviously there is a dependency on Project A defined in Project B. If I use Incredibuild's Rebuild Project option on Project B, it correctly builds Project A and foo.exe is successfully built. Project B has a custom build tool file which should cause foo.exe to be ran with a command-line argument to the file it's supposed to parse. However, trying to launch foo.exe in this way always returns an error:
CustomBuild:
Running Foo
'path to executable\foo.exe' is not recognized as an internal or
external command, operable program or batch file.
C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(171,5):
error MSB6006: "cmd.exe" exited with code 9009.
Interestingly, if I then use Incredibuild to build only Project B (i.e. using the Build Project option), everything is ok - it correctly picks foo.exe from the location it was built to on the previous, failed, build. This makes me think that the path, at least, must be ok.
Can anyone suggest why the executable cannot be ran as part of the rebuild? Is it a timing issue, e.g. Project B commences before foo.exe is known to the file system??
It all works under Visual Studio's regular (re)build. It's just the Incredibuild rebuild which fails. Note that I'm doing all of this through the Visual Studio IDE, not from a command line.
Edit: this is the freebie version of Incredibuild that I'm using (the one which comes with Visual Studio), so all of the build is on the local machine.
I contacted the Xoreax technical support about this in the end and they told me that this is a "rare but known issue that is related to one of our extra accelerating features".
Their first suggestion was writing an executable which simply sleeps "for a few milliseconds" and having that run as part of the custom build tool post-link. This did indeed solve the immediate problem, but the solution I'm building has numerous similar problems and adding this delay in everywhere quickly became tedious and didn't always work. It felt like a fudge anyhow.
So I asked if this behaviour can be toggled to off, and indeed it can. In Visual Studio the Incredibuild menu has an Agent Settings option, and from the invoked dialog's Visual Studio Builds|Advanced page it's a simple case of unchecking the Enhance throughput using out-of-order tasks spawning option.
Case closed.
There are options how to offload or intercept custom tools during your build process. Try to look onto "c:\program files (x86)\IncrediBuild\Samples"
I am trying to run a C code in microsoft visual studio 2015.
For some reason, the run bottom is changed to "Attach to a process".
And when I attach any of the process, the process wouldn't start to run (command prompt would'nt open).
That's a picture of my visual studio and the attach to process window:
May be because the code you have compiled gives only a Dynamic Link Library (DLL) file. So you need to attach it to a process (.exe file) which will load the (DLL) for execution.
Also, why 0 projects?
I had the same problem on Windows 10. Adding dotnet path as a system varible solved my problem.
This may be helpful for others;
Right click on This PC and select properties.
Click the Advanced system settings.
Then click the Environment Variables.
In the System Variables section, find the PATH environment variable and select it. Click Edit.
Click New and paste your dotnet path (my path is C:\Program Files\dotnet)
I just finished coding my c program in visual studio (VS) and what I had done is just drag the compiled .exe file out of the folder to run it on other computers, except on other computers for that to work I guess I need VS since it says the MSVCR110D.dll is missing which is from VS. So how can I run my program on other computers that don't have VS?
You can use IExpress which is used for distributing self-contained installation packages. It is there in every windows machine preinstalled. Using this utility you can make the executable .exe which will be incorporated with dependent dlls. You can see Step by step guide, to see how to use it.
Follow these steps
https://msdn.microsoft.com/en-us/library/3w7axy17.aspx
In your output window it will show you where you can find the exe file, usually something like "ProjectName/Debug/Release/"
If you have added any external libraries you will have to copy any DLL files in that folder with the exe (You can combine them with some applications if needed)
You will also have to make sure that you have the correct version of the .NET Framework on the PC that you are trying to run your program on
We're a great fan of using ADPlus in the Debugging Tools for Windows for customers who are experiencing crashes or hangs. However, the big problem we have is trying to explain what the customers need to type in order to run it. We would send them a script, but it seems that the precise incantation depends on whether the user is on 32 or 64-bit and precisely which version of the debugging tools they downloaded.
Our convoluted instructions at the moment go something like this:
Find where the debugging tools installed -- it may be c:\program files (x86)\Debugging Tools for windows (x86) or c:\program files\Debugging tools for windows (x86) or some other variant
If you're running a 64-bit app then you'll need c:\program files\Debugging tools for windows (x64) instead
Find out what your user directory is, it may c:\users\jim or z:\documents and settings\jim
Start a command prompt and type:
<whatever path you had above>\adplus -hang -pn myprocess.exe -o <your user dir>\crash_dumps
Obviously this has plenty of scope for going wrong, and isn't the best user experience, so I'd like to be able to send the user a batch file or other script that will detect:
Location of the Debugging Tools
User's home directory
So, is there a way of finding out where the debugging tools are installed? If the location exists in a registry, can that be easily extracted in a batch file? Can the user's home directory also be found from a batch script? My system (Win7-64) has an environment variable HOMEPATH. Can I assume that exists?
In answer to my own question: it looks like the simpler approach is just to run ProcDump instead, as that has a hang mode, and can be unzipped and run from any location:
procdump -h -accepteula %HOMEPATH%\Desktop\crashreport.dmp myprocess.exe
I've been using Visual Studio 2005 for a few years and I've come across a problem which I'm wondering whether its me being stupid. I'm using Windows Vista and I can't debug a project with an assembly name containg the word "update" without running Visual Studio in administrator mode.
For example, I created a new windows forms application project leaving the default windowapplication1 assembly name and pressed F5 to debug and sure enough the project ran. I then amended the assembly name to UpdateManager and pressed F5 again. This time it wouldn't run and says its requires elevated permissions. Changing the assembly name to UpdatManager (no 'e') and it runs again?
Is this my setup or behaviour in built into Visual Studio?
Awesome problem. You are using an old version of VS, one that doesn't automatically embed a manifest in the EXE to signal Vista that your program is aware of Vista UAC policies. That makes it treat your program like a legacy program, it automatically redirects file and registry access to safe locations.
That works pretty well for old programs, except the ones that are intended to update, patch or install programs. There is no easy way for Vista to see that a program is an installer. Other than, you guessed it, the name of the program.
Start by installing the Vista specific service pack for VS2005. You probably also need to fix what your program is doing and make it UAC compatible.