|
You could also go directly for ntdll.dll, if it doesn't work with that then it's a sign that what you are trying to do amounts to hacking 
|
|
|
|
|
Hacking? Oh for Pete's sake. What I want to do is so simple. If I knew C++ I'd have it done already I'm sure. But I'm trying to do it in c#. I do tech support. I want to be able to send a single executable file to a customer so I can easily make program setting changes WITHOUT guiding them thru using REGEDIT. Because .NET wont let me make those changes when running from a mapped drive, where the program whos settings are I want to change, sits. People have been programming using Win32 API's for years! All I want to do is make one call to bypass .NETS security. In my opinion, much safer than using the .NET configuration tool to open up ALL registry access.
Sorry, I'm just frustrated. If there is an easier way to make that registry change, TRUST ME, I would love to hear it. 
|
|
|
|
|
you could use regsvr32.exe and feed it a .reg file
and you can automate that with a batch file or with the Process class.
|
|
|
|
|
Thanks,I wish I could. But a lot of what I would need to change or set would be dependent on different paths the client may be using. It would defeat my purpose. Be easier to just remote in and make the changes myself.
|
|
|
|
|
I don't understand, you could use a C# app to create a temporary .reg file and launch regsrv32 to execute it, couldn't you?
|
|
|
|
|
Now THAT, is not a bad idea! I little more work than i planed but, great idea! THANKS! But isnt regsrv32 used to register DLL files?
modified on Friday, April 17, 2009 9:06 PM
|
|
|
|
|
It started with a release build that failed to work.
Or actually it is a bit more subtle but it took a lot of work to find that out.
So, the story.
I'm writing a dll that is part of a bigger program. When I'm debugging it, it works fine, nothing wrong. But when I run the release build it first takes 100% cpu and after a while it crashes. This only happens if I run the release build - so neither when I try to debug the release build and ignore the warning that it's optimized, nor when I run the debug build directly without the debugger attached.
Have tried:
* copying the "debug" dll to the release folder of the exe (works)
* replacing all #if DEBUG by #if true (does not work)
* enabling full debug info for the release build (no effect)
* disabling optimization for the release build (works!)
But merely knowing this doesn't solve the problem. I'd like the code to be optimized.
So here is the real question: what is going on here? what could cause this?
I have a small amount of reflection going on, but nothing to serious, just things like enumerating custom attributes and calling a default ctor.. No dirty tricks with MSIL and Reflection.Emit. It does use SetWindowsHookExA but in a completely different part of the program than the failing part which shouldn't have any effect at all - but maybe it does? And it uses Xna.Framework and Xna.Framework.Game (but they should work, they always used to), which is why I'm compiling for x86 only (not AnyCPU).
|
|
|
|
|
harold aptroot wrote: it first takes 100% cpu and after a while it crashes.
Is there any specific error when it crashes?
Are you running the release build on your development machine? If so, you should get the option to attach the debugger only at the point of failure if attaching it before that point somehow doesn't show the error.
|
|
|
|
|
No it just goes unresponsive and windows asks me to close it.. I tried telling it to wait but it just goes on doing a lot of apparently nothing without any noticeable progress..
How do I attach the debugger to it? I remember seeing such an option in VC++, but I don't see it in VC# (I'm using Express now btw maybe that's why?)
|
|
|
|
|
Hi Harold,
do you have multiple threads? and cheap synchronization, say a bool variable set by one thread, read by another? forgot to apply the volatile keyword correctly?
in general: check your loops for things that, by optimization, might be pulled out completely making the loop empty and spinning forever.
|
|
|
|
|
A good suggestion and it was actually my first thought - but as far as I'm aware I only use ManualResetEvent's for synchronization, and that should work shouldn't it?
Mostly it just spawns a few threads and then waits for all of them to finish (not many, say 3 to 8, doing a couple of seconds of work) and BeginInvoke/EndInvoke for some smaller tasks
But I'll recheck everything
|
|
|
|
|
The alternative problem situation is a race condition: say you start a very short thread and clear a flag (a bool or a ResetEvent) then wait for the flag getting set; whereas the right order would be clear the flag, start the thread, wait for the flag.
By optimizing stuff the thread becomes faster and may set the flag before you clear and then test it.
|
|
|
|
|
Also nice suggestion, it's happening in this order: create and clear flag (new ManualResetEvent(false)), create (new Thread) and start thread, the thread runs and eventually sets the flag (Set() on the resetevent)
After starting all threads in this way it begins waiting for the threads.
Old ResetEvents are just discarded.
Is that right?
|
|
|
|
|
That is right if executed once; and it may be right if inside a loop.
If both sides contain a loop and need to synchronize each iteration of it, then I consider it bad style to create new ResetEvents (or whatever synchronization object) all the time, since one party could be manipulating the old/new object whereas the other is manipulating the new/old object (which they probably share through a shared variable, say a class member) probably leading to a stand-still.
I would suggest you add some logging: let your threads report somehow what they are doing. I always have a protected void log(string s) method present in all my classes, it's implementation could be as simple as Console.WriteLine(s); or could be somewhat more complex, possibly with the current time, the current thread's ID, optional file output, etc.
Seeing the system-wide actions in chronological order helps in debugging, much more than breakpoints and other fancy stuff if you ask me. The Visual goodies are more suited for solving very local problems, once you now about where they are.
|
|
|
|
|
It normally happens 3 or 4 times, a bit spaced out, not as a loop.
I will add logging now
|
|
|
|
|
Did you try attaching and breaking into the debugger (Debug -> Break All) once the application becomes unresponsive?
|
|
|
|
|
I would like to, but the problem doesn't occur during debugging
|
|
|
|
|
You don't really need to be debugging. Just build the application in release mode with debug information, run the app then and attach it to the debugger. AFAIK, the debug/release detection is done based on the app launching your app, so as long as you don't run your application from Visual Studio, you should be able to reproduce the problem.
|
|
|
|
|
How do I attach it to the debugger?
|
|
|
|
|
If you are using Visual Studio, Debug -> Attach to Process
|
|
|
|
|
That does not exist 
Maybe it's in Pro only?
|
|
|
|
|
Ah, you're using the Express edition?
|
|
|
|
|
Yes 
|
|
|
|
|
If you're desperate enough, you can use the freely available Windbg/SOS[^] to debug the issue. I can walk you through the steps if you're interested.
|
|
|
|
|
Very kind of you, but the problem magically disappeared so it kinda moved to the bottom of the pile.. Until it resurfaces of course
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
