For 64 bit OS, you dont need AWE and even enabling AWE using
sp_configure awe enabled has no meaning.
Refer to Great SQL Server Debates: Lock Pages in Memory by Jonathan Kehayias :
In 64-bit SQL Server, the SQL Server account still requires the Lock Pages in Memory permission in order to be able to allocate locked pages, via AllocateUserPhysicalPages(), but there are a couple of big differences:
The underlying reliance on AWE-mapped memory is removed. You do not need AWE in 64-bit SQL Server; the awe enabled sp_configure option has no meaning. The continued use of the same AWE API function is purely to ensure that the allocated pages are locked.
Memory allocated via AllocateUserPhysicalPages() can be used for both the data cache and plan cache. In 64-bit SQL Server, the plan cache is no longer allocated separately (it now uses stolen pages from the buffer pool)
The memory allocations for AWE in 32bit use the AllocateUserPhysicalPages() API. The memory allocations for lock pages in 64bit use the same API, but they aren't using AWE because the VAS in a 64-bit process is 8TB for user mode space and it doesn't require special mappings through AWE.
Queries timing out has least to do with AWE. There might be missing indexes, outdated stats, poorly configured memory settings and many other stuff that can lead to queries timing out.
What specific version of sql server are you running (along with patch level) ?