I am also experiencing the same issue. 

IIS, PHP 5.3.28, Wincache 1.3.4 - memory leak
CLI, PHP 5.3.28, Wincache 1.3.4 - no memory leak
IIS, PHP 5.5.13, Wincache 1.3.5 - memory leak
CLI, PHP 5.5.13, Wincache 1.3.5 - memory leak

Actually it happens with CLI PHP 5.3.28 as well. I had enablecli=off.

Module Information 

Image Name: D:\Php\5.5.14\php5.dll   Symbol Type:  Export 
Base address: 0x00905a4d   Time Stamp:  Wed Jun 25 23:01:39 2014  
Checksum: 0x00000000   Comments:   
COM DLL: False   Company Name:  The PHP Group 
ISAPIExtension: False   File Description:  PHP Script Interpreter 
ISAPIFilter: False   File Version:  5.5.14 
Managed DLL: False   Internal Name:  PHP Script Interpreter 
VB DLL: False   Legal Copyright:  Copyright © 1997-2013 The PHP Group 
Loaded Image Name:  php5.dll   Legal Trademarks:  PHP 
Mapped Image Name:     Original filename:  php5.dll 
Module name:  php5   Private Build:   
Single Threaded:  False   Product Name:  PHP 
Module Size:  6.26 MBytes   Product Version:  5.5.14 
Symbol File Name:  php5.dll   Special Build:  & 

 
Function details

Function   php5!zend_hash_index_exists+43 
Source Line    
Allocation type   Heap allocation(s) 
Heap handle   0xa713c99d 
Allocation Count   8 allocation(s) 
Allocation Size   2 MBytes 
Leak Probability   80% 


Call stack sample 1

Address   0x00040000 
Allocation Time   00:00:10 since tracking started 
Allocation Size   256 KBytes 

Function Destination

php5!zend_hash_index_exists+43   ntdll!RtlAllocateHeap 
php5!emalloc+588    
php_wincache!alloc_oemalloc+a   php5!emalloc 
php_wincache!copyout_zval+15a    
php_wincache!copyout_bucket+156   php_wincache!copyout_zval 
php_wincache!copyout_hashtable+16d   php_wincache!copyout_bucket 
php_wincache!copyout_zval+202   php_wincache!copyout_hashtable 
php_wincache!zvcache_get+a9   php_wincache!copyout_zval 
php_wincache!zif_wincache_ucache_get+c8   php_wincache!zvcache_get 
php5!execute_ex+b26    
php5!zend_execute+14b   php5!execute_ex 
php5!zend_execute_scripts+de   php5!zend_execute 
php5!php_execute_script+14c   php5!zend_execute_scripts 
php!sapi_cli_single_write+f99   php5!php_execute_script 
php5!zend_save_error_handling+700    
php5!php_printf    
php5!zend_make_printable_zval+100    
php5!php_execute_simple_script+f0    
php5!php_log_err+100    
php5!zend_get_configuration_directive+10    
php5!php_remove_tick_function+20    
php5!config_zval_dtor+1e0    
php5!php_stream_read+350    
php5!zend_stack_is_empty+40    
php5!config_zval_dtor+180    
ntdll!_except_handler4    
php!sapi_cli_single_write+9079    
kernel32!BaseThreadInitThunk+e    
ntdll!__RtlUserThreadStart+20    
ntdll!_except_handler4    
ntdll!FinalExceptionHandlerPad17    
php!sapi_cli_single_write+8c56

Definitely leaking for arrays.  It looks like we're leaking a zval, a HashTable, and any nested zval's or HashTables of the Array that exists in the user cache, on every call to wincache_ucache_get().
For integral types, the return_value does not flow through the array copying path, and does not leak.
Under investigation for how to fix this.

The array objects (zval & HashTable objects) are allocated with emalloc, so the "leaked" items are allocated out of per-request memory.  This means that the memory will be free'd when the request/script completes.  I believe this reflects the intended use of the wincache_ucache_get function: it should be used only a few times within the lifetime of a single HTTP request/script execution.
Since the backing for the values in the array item returned from wincache_ucache_get is in memory controlled by Wincache, we hand-create the HashTable such that it doesn't have a destructor, and therefore doesn't deref the contained zval's (or free the items pointed at by the zval's zvalue_value).  Hence, Wincache depends upon the callers only calling wincache_ucache_get infrequently during a single script.

[Mopping up old bugs]

Resolving this as "By Design", since this WinCache is doing exactly what it's supposed to do.

Thx!
    --E.