I am coding delete/pack routine in Visual Foxpro 8.0.
I am getting "File in use" when running the following code when the "Use" statement uses "Exclusive":
USE dbbudget_log EXCLUSIVE
DELETE ALL
pack
use
SET SAFETY ON
I have even tried SET EXCLUSIVE ON/OFF and still get "File in use" error.
Any suggestion eliminating the error?
Best Regards,
Nick
It means that the file is being used in another session already. That session might belong to the user who tried to use exclusively or someone else on the network.
Also, use ... EXCLUSIVE does NOT guarantee that the file is used exclusively (if it is already opened in shared mode then it continues to be used in shared mode and no error is raised).
You could code defensively against both situations like this:
local llHadError
On error m.llHadError = .T.
select 0
use dbbudget_log exclusive
zap
use
on error
* if m.llHadError && something went wrong
* ....
* endif
Related
My software (with admin priviledges) periodically performs the following query via WMI to know the status of the CPU:
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_PerfFormattedData_PerfOS_Processor");
ManagementObjectCollection collection = searcher.Get();
Suddenly (meaning after months where the result of searcher.Get() was always available) the command started sitting down and throwing an "Invalid query" Exception after a timeout. I cannot say what's changed in the machine before this happens.
I confirmed this error by testing it with tool wbemtest:
The error happens everytime, even after reboot. How can I debug it?
System is Windows 10 x64 IoT Enterprise v1607.
The solution is explained in this article.
Anyway, I still have not understood the reason why the counters may get corrupted. Any comment on this?
I ran into this issue on a Windows 7 machine separate from a network and required to be kept around for various reasons.
At first I thought it was an admin thing (the program runs as a normal user) because system event viewer error 2011 hints at that.
However, it's fixed with this:
lodctr /r
I don't fully understand why, but this article was my source:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/4d574e10-17f5-4599-95d6-2492ede3cfef/wmi-query-from-net-application-cause-2011-error-event?forum=netfxbcl
I am new to kernel mode windows driver development and having issues getting debug information out of the WFP callout samples. I am looking for either more options or tips of what I am doing wrong with the options I have been trying.
To start with I downloaded the WFP sampler and followed the instructions in it's description. I am using a Windows 8.1 x64 host and a Windows 7 x64 target connected via a simulated serial cable. They are both VirtualBox VMs.
The primary command I am debugging with is
WFPSampler.Exe -s PROXY -l FWPM_LAYER_ALE_BIND_REDIRECT_V4 -aaid "C:\Program Files (x86)\Internet Explorer\iexplore.exe" -pla 10.0.2.15 -v
Where 10.0.2.15 is the IP address of a diffrent network interface than the routing table is endign traffic to. I also used the following inspect command as recommended by the instructions:
WFPSampler.exe -s BASIC_PACKET_EXAMINATION -l FWPM_LAYER_INBOUND_IPPACKET_V4 -v
"netsh wfp show state" shows the callout and filter associated with the expected layer
However I never got any messages from traceview as per the last steps of those instructions. Tracelog had similar lack of output. This was true with or without WPP tracing enabled on the driver project. I also tried higher verbosity, all to no effect.
Additionally the remote debugger in visual studio either stopped at "Driver Post Install Actions (x64) (possible reboot): Pass" or "Waiting to reconnect..." rebooting the target did not cause more output in the Debugger Immediate Window (the Output window never got any output). Rebooting the target VM did not get any unusual prompts (some things I read implied it should). The reconnect checkbox when setting up the debugger sometimes caused it to get past the "Waiting to reconnect..." prompt, other times it was not needed. I set a number of breakpoints that should have been hit including one at the top of every classify function and none were ever hit.
I tried to debug with WinDbg, but well, frankly I can't find the documentation about how to use this tool. I start it on the target machine and chose kernel debug, local. then I get a prompt that tells me the symbol search path is invalid and no clue what I am supposed to set it to. Any documentation on how to use this tool as opposed to just installing it may be helpful if it lets me debug these callout drivers.
Finally of course I tried just debugging it based on symptoms and I find that the examination callout does nothing as far as I can tell, while the proxy callout just eats all traffic from the targeted application, with one caveat. That caveat is that when I target firefox or chrome with the proxy callout and try to launch that app it fails to launch a UI and the partially started process cannot be killed from task manager.
I assumed that behavior may be the result of the sample failing to check FwpsQueryPacketInjectionState but modifying as best I can figure out that should be used does not seem to change the behavior.
So in short I am stuck and need direction please?
I started experimenting with the WFPSampler and also discovered that tracing didn't work. Oddly enough, there was a lot of additional code to make WPP tracing work on multiple OS's, but the sample doesn’t capture any trace events. So I debugged it and found the call to the nt!WmiTraceMessage always passed 2 as the TRACE_HANDLE. This seemed bad. Safe it to say, this wasn't exactly straight forward to unscramble WPP macros and then finally find the origin in the .vcxprog file. The definition of WPP_COMPID_LEVEL_LOGGER(COMPID,LEVEL)=2 is incorrect. While I was there, I also converted the DbgPrintEx Levels to match Tace_Level by adding 2 so Error/Warning match the model.
Complete the following steps for SysLib/WFPSampler and Sys/WFPSamplerCalloutDriver
Open the Project
Right Click on WFPSamplerCalloutDriver
Unload Project
Right Cick on WFPSamplerCalloutDriver
Edit WFPSamplerCalloutDriver.vcxproj
Type: WppPreprpocessorDefinitions
Change this definition in both places in the file:
To:
<WppTraceFunction>DbgPrintEx(COMPID,LEVEL,MSG,...)</WppTraceFunction
<WppPreprocessorDefinitions>WPP_COMPID_LEVEL_LOGGER(COMPID,lvl)=(WPP_CONTROL(0).Logger),;WPP_COMPID_LEVEL_ENABLED(COMPID,lvl)=(WPP_CONTROL(0).Level >= lvl+2)</WppPreprocessorDefinitions>
Save the File
Right Cick on WFPSamplerCalloutDriver
Click Reload Project
Rebuild
I believe if you adopt this model of using DbgPrintEx as your trace function, you can switch to WPP without editing the entire project. However, I still think it's better to just convert in your program.
Cheers,
John
Not exactly an answer to this question, I never got a debugger working, but an explanation of why the wfpsampler sample didn't work for proxying by ALE layers. The end goal of this project.
In the Proxy callout there were these lines (i think before my refactor they were in the PerformProxySocketRedirection method):
if (ipProtocol == IPPROTO_TCP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->tcpPortReservationToken;
else if (ipProtocol == IPPROTO_UDP)
pBindRequest1->portReservationToken = (pRedirectData)->pProxyData->udpPortReservationToken;
udpPortReservationToken or tcpPortReservationToken should have been initialized by a call to CreatePersistentUdpPortReservation or CreatePersistentTcpPortReservation and this is handled in a helper function named HlprWinSockCreatePortReservation, but said helper function is never called, from anywhere in the entire solution. Those fields are never set, anywhere, ever.
Additionaly, that value only needed set if the local port was being changed, but that block of code executed regardless.
remove these lines, and so long as you don't change the local port, the ale redirect sample works as you would expect including changing the outgoing interface if you change the local IP. If you do need to change the local port, you will have to use HlprWinSockCreatePortReservation to initialize the appropriate port reservation token variable in the PROXY_DATA. This must be done in user mode, so you need to do it in the service when setting up the filter.
Disclaimer: I think that is the only important change, but if you are here for a solution to this problem know that while tracking this down without a working debugger i changed a ridiculously large amount of code so there may have been more to it I forgot over the course of the last few weeks. But I did go back and verify that that block was always called and those fields were never set in the original.
I have a Visual Basic 4 32 bit application which results in a
Run-time error '5':
Invalid procedure call
I start WinDbg and do
sxe *
to break on all exceptions. However, it displays the message without breaking into the debugger before.
If I break at the time of the message, the callstack is not very useful. Is there a trick to break-in on Visual Basic 4 applications at the time the problem occurs?
Problem FAQ:
Can you run it in the IDE?
Yes I can and I can probably fix the bug when I do that. However, I'd like to get some more information at the time the end user runs the application so that I don't need to be able to reproduce it.
What do you want to do in case you find the cause of the error?
Well, it depends on the type of the error. Maybe I can fix it, maybe I can't. Usually I get some very helpful information out of WinDbg.
When does the error occur?
It occurs reproducibly when the user presses a close button on a form.
What does the application do?
Oh, that's a good question. I don't exactly know. It uses RS232 communication but it's not yet involved.
Do you know anything about the data the user can enter?
I almost know nothing about it. In this particular case, it's not necessary to enter data.
The error is from the VB virtual machine not from an API.
I can't see how WinDbg would be useful on VB4 which is interpreted and is in P-Code.
Visual Basic run-time error 5 Indicates one of the following:
An invalid collection or property name was entered.
An out parameter was NULL.
The value is not one of the supported values or falls outside the supported range.
The property is read-only.
The property cannot be changed after the object is created.
An invalid index was entered.
And in case it's an API call VB uses LoadLibrary and GetProcAddress.
Some controls have lost default values over time and this can cause the first.
The third can happen if modern technology exceeds the program's expection, e.g. disk space.
Also see (sorry no links, they are on my hard disk)
Q131007 HOWTO: Use Windows NT WinDbg.exe with Visual Basic (it's for NT 3.5)
Q166275 HOWTO: Debug a Native Code Visual Basic Component in VC++ (talks about what you can see in VB in a debugger)
VB4 can't make symbols
As the error occurs when the users presses the close button i assume there is a (very tight) loop running which doesn't receive the expected data (probably a nullstring)
I expect that that loop is continuously reading data from the RS232 device and the RS232 is on the form which is being closed, even though it is not involved the connection might already be open and polling
What you should do is exit that loop and close the connection with the RS232 device before closing the form. You might be able to do that in the Form_Unload() event, but it might also have to take place before that, so you might have to do it in the code of the close button ... make sure though that the user won't be using the X to close the form though
Personally i would run the program from within the IDE, this will point you to the errornous part of the code directly and gives you the opportunity to watch the contents of the variables involved and control states ... that is much faster than taking a guess based on the data of WinDbg
I've asked the very same question here :
Why does my program say "folder does not exist" when run on Windows 2008?
but none of the answers were satisfying and my problem still exists , so I decide to ask it in another way with more detail cause this problem really irritate me and we need to solve this , otherwise we have to write the similar application in another language which means waste of our time.
program written in delphi 7(32 bit)
environment running this program is : windows 2008 r2 64-bit
the task program try to do : creating 3 folders then copy an sound file and compress it using lame commmand line (lame.exe) and save changes into database
error I get : "THE 'folder' does not exist . the file might have been moved or deleted , Do you want to create it?" and it cause the program become halted
things I have done :
1- try to run the program as an administrator
2- check eventlog but no clue
3- triple check the required folder and all of them was correct
4- read this KB: http://support.microsoft.com/kb/927387
BUT still I am seeing this bloody error.
I have uploaded the picture of the error here as you see it clearly :
http://i28.tinypic.com/9to6qr.jpg
The folder name is C:\Upload_ABC\\2010\07\27\:
please notice I haven't written that unwanted dialog-box inside my program I believe windows 2008 attach it or bring it on my application.
please please please give me some idea or let me know what should I do ?
best regards.
C:\Upload_ABC\\2010\07\27\
You have two backslashes in your path. Use debugger to see why.
Have you checked the access rights for that folder structure with regard to the account the Delphi program is running from? Windows Server systems tend to be more restrictive in what a user is allowed to do than Windows on workstations are.
In addition I suggest to strip down a copy of the program to the relevant functionality to show the error. With this you get at least a chance that anyone around may test it on another system.
Furthermore you can try to compile it with D2010 and see wether the error persists. If it does, you might have a chance to find the problem running the D2010 debugger. If you don't have D2010 at hand, you might install the trial just for this purpose.
What is between the two consecutive backslashes in your path? Is there really nothing between them or have some characters been removed because they are Unicode and D7 doesn't support Unicode?
As there is nothing in between the two consecutive backslashes...
It does sound like Windows is getting its grubby little fingers in between your program and your access of the files. Either the folders have not been created, or you are being denied access once they have. And as the changes you are trying to store in your database involve compressed files, virtualization seems to be the culprit as explained by the link you yourself provided.
A couple of avenues to try:
Remove any compatibility settings on your exe (right click|properties|Compatibility tab) that could trigger Windows to butt in. Also don't forget this can be triggered by things like "setup" or "update" as part of the executable name.
"Save your application's data in a folder under your user profile."
Such as c:\users\\documents or some such (better not hardcode it in actual production code, but ok for debugging). That after all is exactly the advice the linked msdn article is giving for scenario 2 "you cannot find the files or folders you just created"
If you can't debug on the machine where it is running, go back to old school debugging: add trace messages to your code to show where in the code you are (and have been) and show them in a memo on a separate form or some such.
Make sure you don't "eat" any exceptions that could give you extra information about what is going on.
The problem:
We use a program written by our biggest customer to receive orders, book tranports and do other order-related stuff. We have no other chance but to use the program and the customer is very unsupportive when it comes to problems with their program. We just have to live with the program.
Now this program is most of the time extremely slow when using it with two or more user so I tried to look behind the curtain and find the source of the problem.
Some points about the program I found out so far:
It's written in VB 6.0
It uses a password-protected Access-DB (Access 2000 MDB) that is located a folder on one user's machine.
That folder is shared over the network and used by all other users.
It uses the msjet40.dll version 4.00.9704 to communicate with access. I guess it's ADO?
I also used Process Monitor to monitor file access and found out why the program is so slow: it is doing thousands of read operations on the mdb-file, even when the program is idle. Over the network this is of course tremendously slow:
Process Monitor Trace http://img217.imageshack.us/img217/1456/screenshothw5.png
The real question:
Is there any way to monitor the queries that are responsible for the read activity? Is there a trace flag I can set? Hooking the JET DLL's? I guess the program is doing some expensive queries that are causing JET to read lots of data in the process.
PS: I already tried to put the mdb on our company's file server with the success that accessing it was even slower than over the local share. I also tried changing the locking mechanisms (opportunistic locking) on the client with no success.
I want to know what's going on and need some hard facts and suggestions for our customer's developer to help him/her make the programm faster.
To get your grubby hands on exactly what Access is doing query-wise behind the scenes there's an undocumented feature called JETSHOWPLAN - when switched on in the registry it creates a showplan.out text file. The details are in
this TechRepublic article alternate, summarized here:
The ShowPlan option was added to Jet 3.0, and produces a text file
that contains the query's plan. (ShowPlan doesn't support subqueries.)
You must enable it by adding a Debug key to the registry like so:
\\HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\JET\4.0\Engines\Debug
Under the new Debug key, add a string data type named JETSHOWPLAN
(you must use all uppercase letters). Then, add the key value ON to
enable the feature. If Access has been running in the background, you
must close it and relaunch it for the function to work.
When ShowPlan is enabled, Jet creates a text file named SHOWPLAN.OUT
(which might end up in your My Documents folder or the current
default folder, depending on the version of Jet you're using) every
time Jet compiles a query. You can then view this text file for clues
to how Jet is running your queries.
We recommend that you disable this feature by changing the key's value
to OFF unless you're specifically using it. Jet appends the plan to
an existing file and eventually, the process actually slows things
down. Turn on the feature only when you need to review a specific
query plan. Open the database, run the query, and then disable the
feature.
For tracking down nightmare problems it's unbeatable - it's the sort of thing you get on your big expensive industrial databases - this feature is cool - it's lovely and fluffy - it's my friend… ;-)
Could you not throw a packet sniffer (like Wireshark) on the network and watch the traffic between one user and the host machine?
If it uses an ODBC connection you can enable logging for that.
Start ODBC Data Source Administrator.
Select the Tracing tab
Select the Start Tracing Now button.
Select Apply or OK.
Run the app for awhile.
Return to ODBC Administrator.
Select the Tracing tab.
Select the Stop Tracing Now button.
The trace can be viewed in the location that you initially specified in the Log file Path box.
First question: Do you have a copy of MS Access 2000 or better?
If so:
When you say the MDB is "password protected", do you mean that when you try to open it using MS Access you get a prompt for a password only, or does it prompt you for a user name and password? (Or give you an error message that says, "You do not have the necessary permissions to use the foo.mdb object."?)
If it's the latter, (user-level security), look for a corresponding .MDW file that goes along with the MDB. If you find it, this is the "workgroup information file" that is used as a "key" for opening the MDB. Try making a desktop shortcut with a target like:
"Path to MSACCESS.EXE" "Path To foo.mdb" /wrkgrp "Path to foo.mdw"
MS Access should then prompt you for your user name and password which is (hopefully) the same as what the VB6 app asks you for. This would at least allow you to open the MDB file and look at the table structure to see if there are any obvious design flaws.
Beyond that, as far as I know, Eduardo is correct that you pretty much need to be able to run a debugger on the developer's source code to find out exactly what the real-time queries are doing...
It is not possible without the help of the developers. Sorry.