I'm interested in having many dynamic assemblies loaded on demand.
Since it's possible all these modules may create too much memory pressure, I want to unload them when directed by the OS, or when lack of activity is detected.
How can I unload a previously loaded module? Is quitting the app the only way?
You can't unload a previously loaded module.
briannoyes stated:
This is a limitation of .NET, once an assembly is loaded there is no way to unload it unless you restart the process or load it in a separate appdomain, which opens up a whole separate can of worms we decided not to pursue back in Prism 1.
Source
You may try to let unused objects garbage collected and don't hold them in static containers.
Related
I am using process monitor to track a process. ( I don't know if there is a better tool like that).
Is there a way to search or filter for where exactly I have a specific dll say myName.dll with a specific function DoWork loaded in stack?
The manual way is by double clicking each process and checking stack after symbols are loaded.
Any quick way to do that?
thanks
If you have the name of the DLL, you can monitor a process and find when a specific DLL is loaded.
If you are looking to log calls to a loaded DLL's function, you can use WinAPIOverride.
in my project i injected a DLL(64-bit Windows 10) in to a external process with Manual-map & Thread-hijacking and i do some stuff in there.
In current state i use "RtlCreateUserThread" to create a new thread and do some extra workload in there to distribute it for better performance.
My question is now... Is it possible to access other threads from the current process (hijack it) and add your own workload/code there. Without creating a new thread?
I didn't found anything helpful yet in the internet and the code i used and modified for Thread-hijacking seems to only work for a DLL file. Because i am pretty new to C++ i am still learning i am already thankful for any help.
(If you want to see the source for injector Google GHInjector your find the library on github.)
It is possible, but so complicated and may not work in all cases.
You need to splice existing thread's machine codes, so you will need write access to code page memory.
Logic:
find thread id and thread handle, then suspend thread with SuspendThread WINAPI call
suspended thread can be in wait state or in system DLL call now, so you need to analyze current execution stack, backtrace it and find execution address from application space. You need API functions StackWalk, and PDB files in some cases. Also it depends on running architecture (x86, amd64, ...). Walk through stack until your EIP/RIP will not be in application memory address space
decode machine instruction (it will be 'call') and splice next instructions to your function call. You need to use __declspec(naked) declared function or ASM implemented one for execute your code and replaced instructions.
ResumeThread
This method may work only once because no guarantees that application code is executed in loop.
I want to use my Unix module in order to write to another process memory (I would like to do it in kernel mode and avoid the pthread interface).
I have to use function (like do_mmap(..), do_unmmap(..), sys_mprotect(..), etc.) which affect the current process memory instead of the process I'd like to it to affect.
So I figured, I need find a way to do a context switch to the process I want in order to make the process I want the current. I tried to copy the implementation of the schedule() with a minor change:
I replaced the line:
next = pick_next_task(rq);
with:
next = myNext;
My problem is that schedule requires so much structs and functions which I can't include, so I have to re-implement them. it seems pretty bad to do such a thing. Do you have any suggestions?
I want to avoid to modify the existing kernel, so I won't have to force the users to restart and modify their operating system in order to use my program (which is why I use modules).
By the way, I use the "2.6.38-11-generic" version of Linux.
Use the get_user_pages() function to get the pages of the target process (more precisely, its mm_struct)
Map the page(s) that you need via kmap() or kmap_atomic() (depending on the context)
Write/read at the address returned by the mapping (withing a page size).
Destroy the mapping via kunmap() or kunmap_atomic()
I have VB.NET application in which one of the form has IE control in it, the application starts initially with memory size consumed around 9 MBs, but when IE form is launched, the memory consumed rises to 27 MB, and when that form is closed, the memory reduces merely by 3-4 MBs, so why memory allocated to IEFrame is not de-allocated automatically? is there any work around to solve this issue? if possible, launching the form as a separate process would be helpful.
If you make sure to dispose the form properly, the garbage collector should free up that memory eventually. Running the IE control in a separate process should not be necessary.
However, if you are using IE 7, you might want to read this question about memory leaks.
Why not just put that form in a separate application if this is an issue? There are plenty of ways you can pass whatever data between the two apps.
The still allocated memory might not be an issue at all. If you have sufficient available memory in the computer the .NET Garbage Collector will not run to clean up. Only when you need the memory the GC will kick in.
If you want to make sure it is a leak you could do the following:
Make sure you have no references to the form in any way.
Call GC.Collect()
See if the memory is still claimed
Do not put the GC.Collect() in the final build; it's just to make sure you are not hunting ghosts.
Here's an obscure Friday Morning question:
Is it possible in LabVIEW to get the callees of a VI without loading the entire VI into memory? For instance, by reading static information from the binary?
Thanks
Well there is the private/scriptig method App.Read Linker Info From File, I don't think this will load the VI into memory, for more info have a look at the LabVIEW wiki (currently off-line , here is a Google cached page) page on the linker method.
The linker method will return all the info on the VI and it's external needs (VIs, DLLs, CHMs etc).
Ton
No, I don't believe so. When you open a reference to the top-level VI, it will be loaded into memory. That's even before you have the opportunity to query it for its callees.
Ton's answer is correct. The mentioned method is an application instance method not a VI reference method. You supply the path to the VI in question to that method and it will then parse the VI structure and extract all the relevant linker information without loading the VI as such into memory (Obviously it will read in the information from the file into memory to parse it but it will not load/instantiate the VI itself).
The problem with that node is however that it is private, because it has changed its interface in the past and may do so in the future again without warning. There even was a case between 7.0 and 7.1 or so, where the interface changed without any warning in the form of a broken arrow, but when executing it with the old data structure it would simply crash. As a private node that is fully valid, as no warranties are made about the functionality of private nodes.