Thursday, December 24, 2009

Windows logs off immediately after logging in

After upgrading the hard disk on my laptop to a bigger capacity, I ran into an issue where Windows logged me off immediately after logging in. After reading a number of posts online and a couple of attempts in vain, finally found the one that explained the origin of the issue.

Here is the link.
http://www.troublefixers.com/windows-logs-off-automatically-while-login/
"Guti" response on Sep 7th, 2009 is on the mark.

http://support.microsoft.com/kb/223188 - Problem as stated from Microsoft Support

The question thereafter is how do you fix the registry key when the system does not let you log in. There are a number of articles that state how to access the registry remotely and you try this and that and the clock goes by without making any progress due to any one of the following.
  • your system may not be on the network

  • you may have turned off "Remote Registry" service from starting up.

  • cannot seem to get remote registry access working

  • in my case, the laptop was not even "pingable".

Here is what I did to fix that and mine is Windows XP.
  • put the old drive (smaller) back in my laptop and booted it up.

  • put the new and bigger hard disk back in the USB enclosure and connected t to the laptop.

  • located the registry file :\windows\system32\config\system.

  • used a binary file editor such as "TextPad" to open this file.

  • moved all references such as \DosDevices\C: to \DosDevices\X: (Pick an unused drive etter as appropriate for your laptop). There may be more than one occurrence of this string in the file and you need to replace all of them.

  • moved all references such as \DosDevices\E: to \DosDevices\C: (E was the drive letter assigned when the bigger hard disk enclosure was connected the first time).

  • saved the file and then replaced the old hard drive with new hard drive.

  • voila!

Ensuring only one active BPEL instance for a unique transaction

We noticed some users managed to submit a form more than once that led to the starting of two or more BPEL process instance of the same kind for some long running transactions.

Though any subsequent messages meant for this process were handled and processed by the process manager, it led to data inconsistency issues because of two active processes for the same transaction id.

We went down the familiar path of preventing a user from creating such a condition and it was getting harder and harder to fix it. So we decided to approach it from the process side and this is what we did to enable only one active process instance for a given transaction (correlation id).

- added a new message and an operation namely "ignore"
- implemented an event handler for "ignore" on the process's main scope. This handler did not to do anything other than sinking the message.
- set up correlation on this event handler to match the correlation id of the transaction.
- removed the message and operation from the WSDL for ignore before distributing it to the client to avoid any confusion.

This worked because any attempt to start a new process due to duplicate submissions
fails due to a conflicting receive condition created by the event handler for the main scope. This may dump quite a bit of exceptions in the logs, but it helped!