Facing one sporadic issue in legacy application developed in VB6. Application produces intermediate file and then tries to delete it once required output is produced. Application does delete files properly but sometimes, I am getting error stating "Path/File access error". I have tried adding delay to delete but this issue is not getting resolved.
I wanted to search if there is any possibility to check process name which has acquired lock in VB6. I tried searching but no luck so far.
Could anyone please tell me any way I can get process name which has locked file and causing to not delete?
Please note that this issue happens infrequently.
Windows does not keep a global database of who has what file open. This is for speed reasons. Although it does keep a list of other computers with files open on this computer.
For debugging purposes you can enable a global database. Remember to un-enable it.
So to enable
Openfiles /local on
then reboot.
To query
Openfiles /query /v
See
Openfiles /?
Openfiles /local /?
Openfiles /query /?
Related
Please help me for solving this error error
Unable to write to output file 'C:\Users\Dell\Documents\Visual Studio 2008\Projects\WindowsApplication1\WindowsApplication1\obj\Debug\WindowsApplication1.exe': The process cannot access the file because it is being used by another process. WindowsApplication1
The process cannot access the file because it is being used by another process.
This means that either your exe is already running (perhaps outside the IDE) or it's been opened for editing in another application (debugger?).
Close the exe down and try again.
I want to kill RunDll32 process which is started from my install directory.
So if I use
${nsProcess::KillProcess} "rundll32.exe" $R0
It kills all the rundll32 processes on the system which I don't want to happen.
IMO, I have two options to fix this,
1. Identify interested process from commandline parameters
2. Identify from process startup directory (current directory).
I see there are few plugins to find the process but what they do is they just return found or not found. Instead I want IDs of the processes or list of these processes and then I'll check each process for command line or startup directory information and will act on the the required process.
BTW, I checked following plugins
http://nsis.sourceforge.net/FindProcDLL_plug-in
http://nsis.sourceforge.net/Processes_plug-in
http://forums.winamp.com/showthread.php?t=230998
Thanks
I fixed by using wmic query as follows:
StrCpy $1 "wmic Path win32_process where $\"name like 'Rundll32.exe' and CommandLine like '%$0%'$\" Call Terminate"
nsExec::Exec $1
If you control the .dll then the best option is to provide some sort of way to shutdown the app in a clean way. Perhaps you could find a window based on its class name and send it a WM_CLOSE message.
If you just need to shutdown the application during upgrade/uninstall then the LockedList plug-in is much better than just killing processes...
I'm using freepascal. So after I run my code compiler creates an exe file that should create few text files. However after it creates an exe file it says "Program c:\fpc\2.6.4\bin\i386-win32\maxmin.exe exited with exitcode = 2". No text files are created. If I later run maxmin.exe manually - it works fine.
UAC - disabled and EnableLUA = 0. But I still pretty sure - it is windows 8.1 rights issue problem.
Some possibilities, in descending order of likeliness:
Note that exitcode 2 usually indicates a file not found error.
Working directory. While manually executing you set the working directory by CDing with the shell, and when indirectly executing the program's assumptions about a working directory are not satisfied.
Sometimes locks linger on Windows for a short while. Usually not noticeable in the manual execution time frames, but when programmatically executing programs in quick succession it might happen.
If you have the feeling that the EXE doesn't run at all, it might be an security software issue. After the binary is generated, the antivirus kicks in and wants to scan, locking the binary for a few seconds.
I'm using Visual Studio Professional 2013 and I'm doing some very basic windows forms application.
A month ago, I could do everything I wanted without any problem. But I started some new projects today and for absolutely no reasons, I keep getting this error message when I come to debug or compile:
Debug error BC31019 : Unable to write to output file 'path/form.exe System Error &H80070005&
It can happen simply by changing the size of a textbox or modifying the text content in a label... It's very random... And I can even do an undo (ctrl+z) and then I can debug again, but if I try again to do the thing I did that brought the error message, the same message pops again as I try to run.
After reading a little about the subject, I realized that it was because the .exe file became in read-only mode and when I try to remove it, windows wont let me.
The only thing I can do if I really want to continue, is to restart my computer every times it happens. Then I can continue just like normal as my .exe file is no longer in read-only...
I tried tor run a sfc/scannow in my command prompt to see if i had any problems with my frameworks but everything was fine.
Since, it is when i restart my pc that the bug disapears, isn't anything i can do or run somewhere to do the same thing. I need to find why the exe file goes to read-only for nothing and how to get it back to normal without having to restart my pc every time...
Please help me!
thank you
I came across the same issue and it was related to having a command line argument that VS could not find, then when i clicked stop debugging I ended up in this situation as it seemed VS kept a process running.
I could see this process in task manager but could not end it (it started with the same name as my app)
I found closing VS would release this process.
Restarting VS it would then work ok again.
there may be other ways to reproduce the issue but restarting VS seems to release the file and allow you to continue.
I set the exe properties to Read/write. No effect, but when I set app properties/settings to "Always on top" = False the issue went away and is still away.
I'm using WiX 3.5. Recently, the following WiX error started occurring frequently on the build server:
light.exe (,): error LGHT0301: Failed to open the database. During validation, this most commonly happens when attempting to open a database using an unsupported code page or a file that is not a valid Windows Installer database. Please use a different code page in Module/#Codepage, Package/#SummaryCodepage, Product/#Codepage, or WixLocalization/#Codepage; or make sure you provide the path to a valid Windows Installer database.
Which "database" does the error refer to? (None of the WiX source files have changed in a long time, so I doubt it's a code page problem.)
Other people have reported that this error may be caused by Trend Micro Office Scan, which is indeed installed on the build server. I asked the system administrator to exclude the build directories from the scan, but this error still occurs. How can I determine whether the virus scanner is the culprit? (The error doesn't always occur, so if I disable the virus scanner and the next build succeeds, I still don't know whether the error has gone away permanently.)
The "Disable the ICE validation" worked for me - just a setting through Visual Studio 2012 in the .Setup.
After studying the WiX source code and running Process Monitor, I found that excluding the build directories from the virus scan is insufficient.
Explanation: When light.exe runs, it creates the target MSI file in a temporary directory. (This file is the database that the LGHT0301 error message refers to.) After light.exe closes the MSI file, ntrtscan.exe opens the MSI file for read access and read-only sharing. Later, in the database validation step, light.exe tries to reopen the MSI file for read/write access, and a sharing violation occurs.
Solution: Exclude the temporary directory from the real-time virus scan. On Windows Server 2008, for example, this directory is C:\Users\«username»\AppData\Local\Temp.
This is a common problem with build processes and antivirus. The scanner will detect the new MSI package and try to scan it. Meanwhile the build process also tries to validate it by running the Internal Consistency Evaluators (ICE) suite and you get a failure because the database has a mutex on it.
You should just remove the virus scan from your build output folders. Alternatively decouple the validation from the Light command so that the antivirus scan relinquishes the MSI handle before you run the ICE validation.
I had the same problem which was actually really related to codepages and language settings of my system.
Adding English input language in Windows' regional settings solved the problem on my German Windows installation.
The real cause was Trend Micro real time scanning!
(The following is only for historical reference)
I followed #Michael Liu answer and solved the problem
I had the same problem.
I am not referring to Codepage (or SummaryCodepage) in any of those tags, or in fact anywhere in the WXS. Putting Codepage="1252" didn't change anything.
Finally, I tried adding
encoding="utf-8"
to the XML tag which previously only had a version='1.0' attribute. This fixed the problem, as described in "Failed to open the database" error. - SOLVED
It was also the antivirus program for me.
An easy way to check if the problem is related to the anti-virus program is to disable the ICE validation in the WiX project setting (using version 3.7). This worked for me, and is a permanent setting now, since in our company you can't change the setting of the antivirus software.
This is the most common error I found while using WiX. The easiest solution for this is go to Properties of your project → Tool Settings → (Check) Suppress ICE Validation.