Develop Reference

How to work around intentional waits which are causing false hot paths when profiling?

I'm pretty new to profiling so I don't know how to even approach this issue. Basically, I want to discover why some hiccups in the UI are occurring. Profiler seems to be made for solving these kinds of issues so I went with that. I'm using Visual Studio 2010 on a Windows 8 machine so my only option is instrumentation profiling.
Unfortunately, what I get is a bunch of distracting hot paths that occur because of MessageBox.Show calls and long-running threads waiting for data with Monitor.Wait. These methods, of course, take orders of magnitude longer than the issues I'm trying to understand.
Is there no way to somehow filter-out these long-running methods? Ideally by function name or some other criteria, perhaps elapsed exclusive time.

Profiling is not for UI. Profiling is for calculations and other logic. If you really need to profile UI (which you should not) you can hide message boxes and simulate button clicks. Something like:
#if PROFILE_VERSION
DialogResult result = DialogResult.OK;
#else
DialogResult result = MessageBox.Show();
#endif
Of course you'll need to define PROFILE_VERSION and create new configuration for this.
But really, you should only test your logic.

Aside from hot paths being some of the pointless information profilers give you, here is how I would approach finding your "hiccups".
Most of the time I use random pausing.
I try to collect samples during the slow times (the "hiccups") so I can see what it's doing in that time.
If I get samples that I can see are not relevant, I just ignore those.
If the hiccups happen too fast to do that, there's a more difficult method.
It requires setting a few-millisecond timer interrupt with a handler.
When the suspect code starts, it enables the timer, and when it finishes it disables the timer.
That way, if it takes longer than normal to finish, the timer goes off. If I set a breakpoint in the handler, I can look to see what the program was doing when the timer went off.
That's a way to get a sample.
If I get several samples, that's usually enough to show the problem.

Handling the final incoming COM events after calling UnregisterTypeForComClients()

(context: Windows 10 desktop, no UWP)
For handling Windows Action Center notification activation events I use a LocalServer32 C# console application, STA and Thread.CurrentThread.Join() calls*. This works just fine. The executable is started and I get Activate calls from COM.
You start getting these calls after calling RegisterTypeForComClients and they stop after calling UnregisterTypeForComClients. The problem is, even without real concurrency in my case (at least in my direct communication with the object -- I could be wrong as I'm no COM expert) I expect some final Activate call(s) might still come in just after I called UnregisterTypeForComClients. Missing Activate calls is bad and shouldn't happen. I need to handle events for just a bit longer -- but how much longer?
Is there a by-the-book method of making sure I get all the last COM events? Something of a WaitForComMessageLoopToShutDown method? I don't want to go with 'a one second wait should be enough'.
notes
RegisterTypeForComClients is the equivalent of CoRegisterClassObject in COM.
UnregisterTypeForComClients is the equivalent of CoDisconnectObject in COM.
(*) I know I could use MTA with some synchronization, but the question applies there as well. I don't use MTA because I'd just be serializing stuff with no real concurrency.
edit -- A more elaborate description
My executable application (an out-of-process server) gets started by OLE automation in Windows because 'things' happen for me to handle. I handle these 'events' (calls to the Activate method)
knowing there could me more than one
knowing there could be time between them
using an inactivity timeout of, say, 30 seconds before self terminating
(for the user within this time span clicking multiple items, or Windows processing delays -- the latter being very small)
Upon expiry of my inactivity timeout I stop the COM object with UnregisterTypeForComClients. Now, crux of my problem: I ended my loop handling events but a new event from Windows was sent to my server just before unregister. Windows says: this event (activation) was sent, I scratch it off my list. But - my application hasn't registered it because my handling loop exited already. Event lost! I hope for a solution in the form of:
The issue described never occurs, or
Something along the lines of you need to call xyz until it returns x
As a side note, I started out with the sample (titled 'Sending toast notifications from desktop apps sample' on MSDN) on Github linked to by Hans Passant in the comments. It doesn't address this issue.

CQRS run handlers in specific order

I have a running order for 2 handlers Deleting and Reordering pictures and would like some advises for the best solution.
On the UI some pictures are deleted, the user clicks on the deleted button. The whole flow, delete command up to an event handler which actually deletes the physical files is started.
Then immediately the user sorts the remaining pictures. A new flow from reorder command up to the reordering event handler for the file system fires again.
Already there is a concurrency problem. The reordering cannot be correctly applied without having the deletion done. At the moment this problem is handled with some sort of lock. A temp file is created and then deleted at the end of the deletion flow. While that file exists the other thread (reordering or deletion depending on the user actions) awaits.
This is not an ideal solution and would like to change it.
The potential solution must be also pretty fast (off course the current one is not a fast one) as the UI is updated thru a JSON call at the end of ordering.
In a later implementation we are thinking to use a queue of events but for the moment we are pretty stuck.
Any idea would be appreciated!
Thank you, mosu'!
Edit:
Other eventual consistency problems that we had were solved by using a Javascript data manager on the client side. Basically being optimist and tricking the user! :)
I'm starting to believe this is the way to go here as well. But then how would I know when is the data changed in the file system?

Max suggestions are very welcomed and normally they apply.
It is hard sometimes to explain all the details of an implementation but there is a detail that should be mentioned:
The way we store the pictures means that when reordered all pictures paths (and thus all links) change.
A colleague hat the very good idea of simply remove this part. That means that even if the order will change the path of the picture will remain the same. On the UI side there will be a mapping between the picture index in the display order and its path and this means there is no need to change the file system anymore, except when deleting.
As we want to be as permissive as possible with our users this is the best solution for us.
I think, in general, it is also a good approach when there appears to be a concurrency issue. Can the concurrency be removed?

Here is one thought on this.
What exactly you are reordering? Pictures? Based on, say, date.
Why there is command for this? The result of this command going to be seen by everyone or just this particular user?
I can only guess, but it looks like you've got a presentation question here. There is no need to store pictures in some order on the write side, it's just a list of names and links to the file storage. What you should do is to store just a little field somewhere in the user settings or collection settings: Date ascending or Name descending. So you command Reorder should change only this little field. Then when you are loading the gallery this field should be read first and based on this you should load one or another view. Since the store is cheap nowadays, you can store differently sorted collections on the read side for every sort params you need.
To sum up, Delete command is changing the collection on the write side, but Reoder command is just user or collection setting. Hence, there is no concurrency here.
Update
Based on your comments and clarifications.
Of course, you can and, probably, should restrict user actions only by one at the time. If time of deletion and reordering is reasonably short. It's always a question of type of user experience you are asked to achieve. Take a usual example of ordering system. After an order placed, user can almost immediately see it in the UI and the status will be something like InProcess. Most likely you won't let user to change the order in any way, which means you are not going to show any user controls like Cancel button(of course this is just an example). Hence, you can use this approach here.
If 2 users can modify the same physical collection, you have no choice here - you are working with shared data and there should be kind of synchronization. For instance, if you are using sagas, there can be a couple of sagas: Collection reordering saga and Deletion saga - they can cooperate. Deletion process started first - collection aggregate was marked as deletion in progress and then right after this reordering saga started, it will attempt to start the reordering process, but since deletion saga is inprocess, it should wait for DeletedEvent and continue the process afterwards.The same if Reordering operation started first - the Deletion saga should wait until some event and continue after that event arrived.
Update
Ok, if we agreed not touch the file system itself, but the aggregate which represents the picture collection. The most important concurrency issues can be solved with optimistic concurrency approach - in the data storage a unique constraint, based on aggregate id and aggregate version, is usually used.
Here are the typical steps in the command handler:
This is the common sequence of steps a command handler follows:
Validate the command on its own merits.
Load the aggregate.
Validate the command on the current state of the aggregate.
Create a new event, apply the event to the aggregate in memory.
Attempt to persist the aggregate. If there's a concurrency conflict during this step, either give up, or retry things from step 2.
Here is the link which helped me a lot some time ago: http://www.cqrs.nu/

Is it possible to read a memory value in real time?

I'm looking to have my program read a value from a memory address, and do some work based on the value of the address. The way I have it done currently is that I have the method executed in a timer every 50 milliseconds, where it reads the address and does the work with the value. Is there any way I could possibly hook onto the address and not need the timer, or atleast read the address whenever it gets updated?

It depends on how data is being written to the memory address. If this is data your program writes - you could easily wrap the access to that memory with a method or property (which is a good idea anyways), and raise an event when it changes.
Instead of polling the value, you could then just subscribe to the event.

Old pulling/pushing problem (Interrupts made based on the same concept). You need OS level API hooking when Firefox writes to it's virtual memory. The technique is used for game cheating. NtWriteVirtualMemory is a good choice for hooking since you don't need a global hook (just watch Firefox). Usually global hooks to memory writing are used to detect DLL injection (a weak defense against memory patching). Here you can find a god article about API hooking.

Of course there is, you can use the observer pattern see here.
The observer will execute some work as soon as the value change.

The OS may have debugger hooks where you can immediately trap on any write to the virtual memory page where the variable of interest resides.

Good way of firing an event at a particular time of day?

I have an app that needs to fire off a couple of events at certain times during the day - the times are all defined by the users. I can think of a couple of ways of doing it but none of them sit too well. The timing doesn't have to be of a particularly high resolution - a minute or so each way is fine.
My ideas :
When the app starts up read all the times and start timers off that will Tick at the appropriate time
Start a timer off that'll check every minute or so for 'current events'
tia for any better solutions.

Store/index the events sorted by when they next need attention. This could be in memory or not according to how many there are, how often you make changes, etc. If all of your events fire once a day, this list is basically a circular buffer which only changes when users change their events.
Start a timer which will 'tick' at the time of the event at the head of the list. Round up to the next minute if you like.
When the timer fires, process all events which are now in the past [edit - and which haven't already been processed], re-insert them into the list if necessary (i.e. if you don't have the "circular buffer" optimisation), and set a new timer.
Obviously, when you change the set of events, or change the time for an existing event, then you may need to reset the timer to make it fire earlier. There's usually no point resetting it to fire later - you may as well just let it go off and do nothing. And if you put an upper limit of one minute on how long the timer can run (or just have a 1 minute recurring timer), then you can get within 1-minute accuracy without ever resetting. This is basically your option 2.
Arguably you should use an existing framework rather than rolling your own, but I don't know C# so I have no idea what's available. I'm generally a bit wary of the idea of setting squillions of timers, because some environments don't support that (or don't support it well). Hence this scheme, which requires only one. I don't know whether C# has any problems in that respect, but this scheme can easily be arranged to use O(1) RAM if necessary, which can't be beat.

Have a look at Quartz.Net. It is a scheduler framework (originally for Java).

This sounds like a classic case for a Windows Service. I think there is a Windows Service project type in VS2005/2008. The service coupled with a simple database and a front-end application to allow users to set the trigger times would be all you need.
If it won't change very often, Scheduled Tasks is also an option.

I've written a few programs along these lines.
I suggest #2. All you need to to is keep a list of times that events are "due" at, and every X amount of time (depending on your resolution) check your list for "now" events. You can pick up some optimization if you can guarantee the list is sorted, and that each event on the list is due exactly once. Otherwise, if you have recurring events, you have to make sure you cover your window. What I mean is, if you have an event that is due at 11:30 am, and you're checking every seconds, then it's possible that you could check at 11:29:59, and then not again until 11:31:01, due to the inprecision of the CPU time-slices. So you'll need to be sure that one of those checks (11:29 or 11:31) still picks up the 11:30 hit, and that ONLY one of them does (i.e., you don't run at both 11:29 and 11:31).
The advantage this approach has over checking only on times you know to be on your list is that allows your list to be modified by 3rd parties without your knowledge, and your event handler will continue to 'just work'.

The simplest way would likely be to use Windows scheduler.
Otherwise you need to use one of the Timer classes, calculating how long until the first event. This approach, unlike the scheduler, allows new events to be found by the running process (and, possibly, resetting the timer).

The problem with #1 is that the number of milliseconds before an event may be too large to store in the Timer's interval, and as the number of events increase, your number of timers could get unweildly.
I dont see anything wrong with #2, but I would opt for a background worker or a thread.