Using RequestFiltering feature, other way around

I came across a simple request from customer wherein they wanted to use 'request filtering' feature in IIS by setting 'Allow unlisted file name extensions' to unchecked. Simple request but it created mess to our product and it started showing up HTTP errors. By adding few extensions (for e.g. isapi_redirect.dll) it started working by opening few webpages but failed later. I also tried to use 'Allow URL' feature by adding few URLs but since our URLs are generated dynamically (struts mapping) we can't add each and every URL under this option.
All the options were searched but at the end we could locate 'URL rewrite' which gives handy options to allow or deny based on RegEx or WildCards.
More description can be found in this below link:
http://stackoverflow.com/questions/24034498/iis-request-filtering-allow-url

Some Windbg commands for stack trace

I received a crash dump on Windows for one of the applications. To reproduce the stack trace I used some useful commands below:
1) "C:\Program Files (x86)\Debugging Tools for Windows (x86)\symchk.exe" /r c:\windows\system32 /s SRV*c:\Windows\Symbols*http://msdl.microsoft.com/download/symbols => symchk checks which Windows .pdb is not present under system32 and copies them to the location c:\Windows\Symbols. This command is not required unless you requires to check stack trace related to Windows.
1) .symopt +0x40 => I wasn't having the exact matching .pdb of the respective DLL's. So, this command forces to use the pdb which I have provided.
2) !analyze -v => I makes the output verbose. Display full message along-with stack trace. For e.g. which pdb isn't found.

Apart from these steps provide the location of .pdb in Windbg. In case of multiple paths use `;`.

Export/Import a static variable

I faced a scenario in which I required to export/import (from/to a DLL) a structure pointer variable declared as NULL in a .cxx file.

static Notify_struct *ptr_name = NULL;

Now since it a .cxx file I can't use my Export/Import API, because in-case this file is read undet dllimport it will report compilation error as 'definition of dllimport not allowed'.
So, I moved declared this variable to a header file like this:

extern DLLEXPORTIMPORTAPI Notify_struct *ptr_name ;

This made the DLL to export this variable easily.
Few points to make. I cannot write in the header file:

EXPORTIMPORTAPI static Notification_db *notification_db;

as it reports ‘error C2201: must have external linkage’.

Export/Import template class

I am thankful to this really nice article which helped me to resolve issues to export/import template class instance.
I surfed a lot and couldn't found a way to export/import the whole template class. Instead we need to do explicit template instantiations to achieve this.

For e.g. instead of whole class you do it like this:
template class DLLEXPORTIMPORTAPI Container < int >;

//DLLEXPORTIMPORTAPI is __declspec(dllexport) or __declspec(dllimport)

New Findings While DLLization

I faced a problem where the address of a structure (as a void pointer) is passed from one DLL 'A' to 'B'. Idea is that you store these void pointers to DLL 'B' and call them latter on the basis of some assigned keys. This structure contains data variables and some others functions/structure address too.
So, while fetching the address back from DLL 'B' rest of address pointed by the structure gets corrupted.
So, the questions arises are:
1) Shall we do a deep copy and pass structure instead of pointers.
2) Is passing pointers across DLL's is acceptable?

While looking for the solution I came across this interesting article from IBM. http://publib.boulder.ibm.com/infocenter/zvm/v5r3/index.jsp?topic=/com.ibm.zvm.v53.dmsa3/hdcode.htm.
Below are few highlights of this article:
1) A source file that contains a function call through a pointer that may point to either a function or function descriptor must be compiled as non-DLL code.
2) A source file that calls imported functions or imported variables by name must be compiled as DLL code.
3) A source file that contains a comparison of function pointers that may be DLL function pointers must be compiled as DLL code.
4) A source file that may pass a function pointer to DLL code through a parameter or a return value must be compiled as DLL code.

Try DLL'ze your Legacy code

DLL's are awesome, why to update your whole code for a simple change, just update DLL's. Get DLL's and get your build time down just like a squeezed lemon :) . But have you ever tried getting DLL's for the executable containing nearly 150 libraries and you are handling the legacy code running from last 20-25 years?
Making DLL's of smaller number of libraries are easier but the time consumption in the process of creation if you get into more and more libraries.
Common errors which you may face while creating the DLL:
1) While Linking: Unresolved symbols. To resolve check your link line, you probably have not included the required library.
2) Circular dependency tree: This is most annoying and requires a bit of hard work. Either the dll you are creating is itself is the dependency of a library (of a DLL) that you have included or that library depends on some other which interns depends to it.
3) Linking error, symbol already in libcpmt.dll (static) and msvcrt*.dll (dynamic) both. In such cases check your objects, some of them would have got build with MT flag. Convert them to MD and linking will get succeed.