I have a visual studio load test which I want to run every hour so that I can start to collect some data.
To do this, I thought it would be best to make a little powershell script and put a command like this inside:
Invoke-Expression -command "& '$env:VS100COMNTOOLS..\IDE\mstest.exe'
/testcontainer:"C:\Users\benb\Documents\Visual Studio
2010\Projects\BBPerformanceTest\bin\Debug\HomePageOnly.loadtest""
That command works fine, but sometimes when its run I get a blue screen of death. However, when I run my load test through the visual studio GUI, I never get a BSOD.
two questions:
is it possible to avoid this BSOD?
Is there another way I can schedule my load test?
Thanks
I just called MStest.exe directly in the scheduled task (rather than indirectly through a powershell script). This seemed to solve the problem. Thanks
My first suggestion is to analyze the memory dump file to find the root cause of your crash (it might not be the load test). This article contains information on how to do that: http://support.microsoft.com/kb/315263
In response to your second question: you can also use a batch file instead of a powershell script.
I hope this helps.
Related
I executed an SSIS package using SSDT and Visual Studio. When I try to execute another package I get an error saying "The process cannot access the file XXXX.ispac because it is being used by another process". I have tried rebooting but that is a pain in the behind. How can I work around this error?
While developing an SSIS package I got the error “The process cannot access the file ‘.ispac’ because it is being used by another process”*.
Tried to close SSDT and run it again but, we still got the same error while compiling. Then, after searching over internet, we got the solution:
Solution :
Go to Task Manager–> Details Tab.
Locate the process “DtsDebugHost.exe“.
Kill this process.
There might be multiple instances of this process. Kill all of them.
After doing this, I tried to compile the package again and it was successful.
You might check your patch level. I saw this much more frequently with the 2015 release of SSDT but hasn't bit me too often since then.
Finding and killing a process
Sysinternals has an excellent tool called Process Explorer. It's free, doesn't require an install and helps you see what all is happening on your computer. In this case, you want to find the process that has its grubby finger on your file (MyProject.ispac) and then kill it.
https://helpcenter.gsx.com/hc/en-us/articles/115015880627-How-to-Identify-which-Windows-Process-is-Locking-a-File-or-Folder
A different approach that doesn't require getting Process Explorer running is to change your build from Development to Release (and back again).
Chicken Sandwich No Pickles asks via comments
How can I convert from Development to Release?
In your tool bar, click where you see Development in the dropdown (or right click the solution in Solution Explorer)
In Configuration manager, you may/may not have a listing available under Configuration. Earlier versions of SSIS projects had dev/release configurations predefined but it looks like newer ones do not. If you do not have another option, make one via <New...>
Copy the values from the Development configuration et voilà!
Now when you debug, ProjectFolder/bin/Release will exist and the dtsdebughost.exe will latch onto that file and release the pointers to ProjectFolder/bin/Development/Project.ispac
Here's a simple script you can run in powershell to kill all ssis debug process "DtsDebugHost.exe" and unlock the ispac file.
unlock_ispac.ps1
# if ssis error with 'The process cannot access the file ‘.ispac'
# run this file in powershell
get-process | foreach {
$pName = $_
if($pName.Name -eq "DtsDebugHost") {
$pName.Kill()
}
}
Hi I want to execute a program I made in order to calculate the average result (not deterministic algorithm) and i need to run it A LOT of times. The program prints it's result in a different file everytime so it is not a problem. The problem is that i have to manually run the project thundreds of times, and i could automate it. I'm working ing windows, so i'd run a .bat file which executes the .exe generated into the debug folder, but when i execute that .exe, the program does not work properly, just does it when i push the "run" button. Is there a way of config the "run" button for use multiple times? Note that i need it won't be parallel but sequencially.
Why dont you build a release and trigger that?
To my knowledge, there is no way to start a debug version outside of its debugger.
I have this issue with the System Scheduler. I have created a project using Visual Studio 2010, then I have scheduled its execution at a certain moment of the day, but when I tried to see the execution result nothing had happened, the execution was never initialized. Just for check I created a very simple package that gets the information from one table to another, but when the execution is running using the scheduler the command window appears so quickly that I could not see nothing and besides the package was not executed.
I wonder if maybe there is a problem with this version of Visual Studio and the scheduler because with 2008 version I have never had any problem, and if there is a possible solution for this problem.
This is what I used to do:
First I create a .bat file with the next code
#echo off
dtexec /FILE "Path_to_my_package\Package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
echo Finishing........
exit
Then I specify in the System Scheduler that I want to run this package in a certain without any problem, and now this is not working.
As mmarie said, you should use SQL Agent for automating SSIS packages. The Visual Studio is irrelevant with this issue. If you used the normal scheduler, you should invoke DTExec and pass your package as an argument, you can check the link below for more details:
http://technet.microsoft.com/en-us/library/ms162810(v=sql.105).aspx
However, the better alternative is SQL Agent, where you can create a job and check the outcome in a better way. It is explained in details in the below link:
How do I create a step in my SQL Server Agent Job which will run my SSIS package?
As described in the subject, my powershell environment is executing all external commands in separate windows. In a typical test run of my team's build script, this includes things like:
nuget.exe running for each project in a sln
nunit test runners
It's quite aggravating. The behavior actually prevents me from multi-tasking while running psake builds, since it grabs my mouse/keyboard focus whenever a new window appears/disapears. It also swallows valuable output from assorted steps in our build process.
As per Powershell suddenly opens cmd.exe for executing bats, I checked $env:PATHEXT, but it is set up correctly (includes .EXE in its items, which are a semicolon-delimited list).
I am the only member of the team seeing this behavior, and it appears to be associated with some global/roaming profile for my user, as it is still happening even after I re-imaged my machine.
Any help would be greatly appreciated and I can provide additional info upon request.
Start-process nuget.exe -NoNewWindow
get-help start-process -online
Using Visual Studio 2010 beta, when I run my application within the IDE for debugging, it works perfectly the first time. However, after closing the debug session, either by closing the application or clicking the stop debugging button, all subsequent attempts to debug the application fail with:
Error 1 Unable to copy file "obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The process cannot access the file
'bin\Debug\Application.dll'
because it is being used by another
process.
Handle.exe from SysInternals does show handles open, but even if I close the handles, the error doesn't go away. Any attempts to delete the file manually result in an "Access Denied" error message.
To fix this, I have to completely restart Visual Studio, afterwhich the Debug session will work once and stop again.
I'm not entirely sure when this started happening, but I'm pretty sure it's fairly recently.
UPDATE: After I force close the handles on Application.dll, I get the following error from VS:
Error 1 Unable to copy file
"obj\Debug\Application.dll"
to
"bin\Debug\Application.dll".
The requested operation cannot be
performed on a file with a user-mapped
section open.
What the heck is a "user-mapped section"??
UPDATE 2: It appears that this problem occurs when I have a Form open in Design view when trying to debug. I'm going to do some more troubleshooting and then post my results.
UPDATE 3: I think I've narrowed it down to a form using a UserControl.
To be honest with you, it sounds like a bug in VS2010. For some reason it isn't closing the open handles when the debugger stops. Killing the VS process automatically closes those handles, allowing you to access the file again. As a work around, you might look at unlocker it's free and works exceptionally well. I know that's not a great answer, but it should be faster than restarting VS. You might to consider sending a bug report too...
Unlocker doesn't work on 64-bit OS, LockHunter does though.
Here is how I solved this problem
*I open the project Properties,
*select the build tab,
*Clear the output path,
*and buid(this will create the dll in the root folder)
*come back to the output path and select browse(browse to the bin directory to either debug/release)and voila!
As per Error: Cannot access file bin/Debug/… because it is being used by another process answer by TarmoPikaro, sometimes Visual Studio creates multiple msbuild.exe ghost processes, which persist after build. These ghost processes seem to be causing file locks.
Solution 1 - Kill ghost MSBuild.exe's
Killing msbuild.exe's is a one time solution, it needs to be done per build basis.
You can kill the processes as follows mrtumnus:
taskkill /f /im MSBuild.exe
Solution 2 - Disable parallel builds in Visual Studio
You can disable parallel build once and for all:
Tools > Options > Projects and Solutions > Build and Run > "maximum numbers of parallel project builds" - by default it has value of 8, switch it to 1.
Of course builds are bit slower now, but mileage may vary depending on your use case.
This is related to
Error: Cannot access file bin/Debug/... because it is being used by another process
I've seen the Windows Indexing Service cause this. Disabling it helped. Virus scanners can also be at fault. Mutliple Application.Close() calls can supposedly cause this, too.
Of course, since it always works the first time, I suppose these are unlikely.
Had the same problem. The following things helped
Closing all design files while debugging
using unlocker
Also my application opens a port. While debugging an exception was thrown and program quit. While ending the program I closed the port. That helped too.
But definitely, bug with VS2010.
I encountered the same problem and in my case I had the file in question open in Visual Studio. Closing all files helped.
I faced the same error and I was stuck in it for many days. Finally resolved the issue.
I was working on a project that had many class libraries added in it. I added the reference of these libraries to my main project and mistakenly added reference to same project to itself. So when I removed self reference, it worked.
I had this issue myself. I had the project properties window open and that apparently creates a file lock. Even after I closed the window the file lock remained and I had to restart VS.
P.S. I'm using VS 2019. Just posting this for anyone having the issue I had and coming to this post.
If you get this error on VS Code;
Click on terminal screen and use "Ctrl + C" for stop running.