I want to make an application run slower, it that possible? I have created application which read file created by another process but that process create file and delete it so fast, so it is possible to make that application be slow so I can read file faster?
I tried
SetPriorityClass(GetProcessHandleByName("dd.exe"), IDLE_PRIORITY_CLASS);
and set my process to
SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
but yet the process run faster it is possible to slow it down? thanks.
Modifying the working directory permissions to allow processes to read/write data to new files, but not modify/delete existing files might be a different approach that would work.
See https://superuser.com/questions/745923/ntfs-permissions-create-files-and-folder-but-prevent-deletion-and-modification
See the answer SO : Suspend/Resume a process. Which gives information on the three choices for suspending an application.
They are basically stop each thread. Use the undocumented SuspendProcess and Debug the process.
These are the methods of substantially delaying the process.
Related
I call a DLL written in C++ (VS2012) from a software (LabView) and what it does is uploading a file on a server via FTP.
While the DLL is uploading the file (15MB) it does not let LabView continue with other tasks.
How could this problem be solved?
Regardless of what you have to do on the C++ side to make the call threadsafe, you will need to configure the call in LabVIEW not to run in the UI thread (which I believe is the default configuration, for safety reasons). Double click the node and select the run in any thread option.
Also, if you want to ensure running it in its own thread, you can put it in a separate VI and change the execution settings of that VI to run in a different execution system. LabVIEW doesn't give you direct control of threads, because it manages them on its own, but this should make the VI execute in a different thread.
Operations with FTP are long-term.
It is better to perform such operations in another thread.
I'm new to Windows API programming. I am aware that there are ways to check if a process is already running (via enumeration). However, I was wondering if there was a way to listen for when a process starts and ends (for example, notepad.exe) and then perform some action when the starting or ending of that process has been detected. I assume that one could run a continuous enumeration and check loop for every marginal unit of time, but I was wondering if there was a cleaner solution.
Use WMI, Win32_ProcessStartTrace and Win32_ProcessStopTrace classes. Sample C# code is here.
You'll need to write the equivalent C++ code. Which, erm, isn't quite that compact. It's mostly boilerplate, the survival guide is available here.
If you can run code in kernel, check Detecting Windows NT/2K process execution.
Hans Passant has probably given you the best answer, but... It is slow and fairly heavy-weight to write in C or C++.
On versions of Windows less than or equal to Vista, you can get 95ish% coverage with a Windows WH_CBT hook, which can be set with SetWindowsHookEx.
There are a few problems:
This misses some service starts/stops which you can mitigate by keeping a list of running procs and occasionally scanning the list for changes. You do not have to keep procs in this list that have explorer.exe as a parent/grandparent process. Christian Steiber's proc handle idea is good for managing the removal of procs from the table.
It misses things executed directly by the kernel. This can be mitigated the same way as #1.
There are misbehaved apps that do not follow the hook system rules which can cause your app to miss notifications. Again, this can be mitigated by keeping a process table.
The positives are it is pretty lightweight and easy to write.
For Windows 7 and up, look at SetWinEventHook. I have not written the code to cover Win7 so I have no comments.
Process handles are actually objects that you can "Wait" for, with something like "WaitForMultipleObjects".
While it doesn't send a notification of some sort, you can do this as part of your event loop by using the MsgWaitForMultipleObjects() version of the call to combine it with your message processing.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
\Image File Execution Options
You can place a registry key here with your process name then add a REG_SZ named 'Debugger' and your listner application name to relay the process start notification.
Unfortunately there is no such zero-overhead aproach to recieving process exit that i know of.
Alright so to start this is strictly for Windows and I'd prefer to use C++ over .NET but I'm not opposed to boost::filesystem although if it can be avoided in favor of straight Windows API I'd prefer that.
Now the scenario is an application on another machine I can't change is going to create files in a particular directory on the machine that I need to make backups of and do some extra processing. Currently I've made a little application which will sit and listen for change notifications in a target directory using FindFirstChangeNotification and FindNextChangeNotification windows APIs.
The problem is that while I can get notified when new files are created in the directory, modified, size changes, etc it only notifies once and does not specifically tell me which files. I've looked at ReadDirectoryChangesW as well but it's the same story there except that I can get slightly more specific information.
Now I can scan the directory and try to acquire locks or open the files to determine what specifically changed from the last notification and whether they are available for further use but in the case of copying a large file I've found this isn't good enough as the file won't be ready to be manipulated and I won't get any other notifications after the first so there is no way to tell when it's actually done copying unless after the first notification I continually try to acquire locks until it succeeds.
The only other thing I can think of that would be less hackish would be to have some kind of end token file but since I don't have control over the application creating the files in the first place I don't see how I'd go about doing that and it's still not ideal.
Any suggestions?
This is a fairly common problem and one that doesn't have an easy answer. Acquiring locks is one of the best options when you cannot change the thing at the remote end. Another I have seen is to watch the file at intervals until the size doesn't change for an interval or two.
Other strategies include writing a no-byte file as a trigger when the main file is complete and writing to a temp directory then moving the complete file to the real destination. But to be reliable, it must be the sender who controls this. As the receiver, you are constrained to watching the directory and waiting for the file to settle.
It looks like ReadDirectoryChangesW is going to be your best bet. For each file copy operation, you should be receiving FILE_ACTION_ADDED followed by a bunch of FILE_ACTION_MODIFIED notifications. On the last FILE_ACTION_MODIFIED notification, the file should no longer be locked by the copying process. So, if you try to acquire a lock after each FILE_ACTION_MODIFIED of the copy, it should fail until the copy completes. It's not a particularly elegant solution, but there doesn't seem to be any notifications available for when a file copy completes.
You can process the data once the file is closed, right? So the task is to track when the file is closed. This can be done using file system filter driver. You can write your own or you can use our CallbackFilter product.
I am building an "Application Virtualization" product. I use XML file as a virtual registry.
Virtual applications generated from my software accesses the virtual registry Xml.
It runs , however runs very slow.
I load and unload the XML on every Registry API calls, because multiple process threaded from the parent access a same registry file. This may cause the application to run slow.
Can any one let me know the alternative for XML...
You could use a database instead. It would be faster. Sqlite is lightweight and powerful.
If you load it into memory and operate on it from there then your problem isn't XML.
Profile your application to find out where it's spending most of it's time.
I think you will probably find it's spending most of it's time searching for the item you want to access.
Its text to tree transformation time.
I managed this in my code by Loadaing and Parsing the XML in all processes, only after a write has occured in any one of the process.
Well, you could of course always use the real registry, which is thread-safe and fast...
Otherwise, you'd have to create a separate process that manages your virtual XML registry, keeping the XML structure in memory so it doesn't have to read/write it all the time. Then the processes that need to access it can use IPC to communicate with the registry process.
Another idea, if the multiple processes are not likely to update the registry all the time: keep your virtual XML registry in memory, and write it to disk when changed, but asynchronously via a background thread. When accessing the registry, first check whether the file has been changed; if not, you don't need to reload it.
I'm a newbie C++ developer and I'm working on an application which needs to write out a log file every so often, and we've noticed that the log file has been corrupted a few times when running the app. The main scenarios seems to be when the program is shutting down, or crashes, but I'm concerned that this isn't the only time that something may go wrong, as the application was born out of a fairly "quick and dirty" project.
It's not critical to have to the most absolute up-to-date data saved, so one idea that someone mentioned was to alternatively write to two log files, and then if the program crashes at least one will still have proper integrity. But this doesn't smell right to me as I haven't really seen any other application use this method.
Are there any "best practises" or standard "patterns" or frameworks to deal with this problem?
At the moment I'm thinking of doing something like this -
Write data to a temp file
Check the data was written correctly with a hash
Rename the original file, and put the temp file in place.
Delete the original
Then if anything fails I can just roll back by just deleting the temp, and the original be untouched.
You must find the reason why the file gets corrupted. If the app crashes unexpectedly, it can't corrupt the file. The only thing that can happen is that the file is truncated (i.e. the last log messages are missing). But the app can't really jump around in the file and modify something elsewhere (unless you call seek in the logging code which would surprise me).
My guess is that the app is multi threaded and the logging code is being called from several threads which can easily lead to data corrupted before the data is written to the log.
You probably forgot to call fsync() every so often, or the data comes in from different threads without proper synchronization among them. Hard to tell without more information (platform, form of corruption you see).
A workaround would be to use logfile rollover, ie. starting a new file every so often.
I really think that you (and others) are wasting your time when you start adding complexity to log files. The whole point of a log is that it should be simple to use and implement, and should work most of the time. To that end, just write the log to an unbuffered stream (l;ike cerr in a C++ program) and live with any, very occasional in my experience, snafus.
OTOH, if you really need an audit trail of everything your app does, for legal reasons, then you should be using some form of transactional storage such as a SQL database.
Not sure if your app is multi-threaded -- if so, consider using Active Object Pattern (PDF) to put a queue in front of the log and make all writes within a single thread. That thread can commit the log in the background. All logs writes will be asynchronous, and in order, but not necessarily written immediately.
The active object can also batch writes.